Re: MEMORY credential cache interop between Heimdal and MIT?

[Howard Chu <hyc@highlandsun.com>]

Michael B Allen wrote:
> On Tue, 28 Aug 2007 18:50:05 -0700
> Howard Chu <hyc@highlandsun.com> wrote:
> 
>> Henry B. Hotz wrote:
>>> At this point we're looking for volunteers, not more wishes, but  
>>> here's a wish:
>>>
>>> Instead of always going up the tree visiting all parents, have some  
>>> way to "stop" so you can securely implement PAG semantics.  I don't  
>>> think I'd use it often, but I like the idea of being able to set up  
>>> an "admin" window and a "secure sandbox" window with more/less  
>>> privileges than my default login session.
>>>
>>> I would think the AFS folks would be interested in seeing the  
>>> Kerberos ticket cache scope match the scope of PAG's as well as  
>>> having a PAG implementation that wasn't so dependent on OS-specific  
>>> hackery.  I'm not sure this is easier than what they do now, but if  
>>> it gets AFS and Kerberos on the same page, that's a good thing.
>> You can simply use mmap'd files to accomplish the functionality that Michael 
>> proposed. Unix mode bits on the file will determine which uids can open the 
>> file. Children of a given process can access it through descriptor inheritance 
>> from a process that already has it open/mapped. A process creating a cache 
>> would just have to export an environment variable giving the cache name and 
>> number of the descriptor in use. (Of course, any child process that closes 
>> descriptors or zaps this environment variable would prevent further 
>> propagation.) e.g. KRB5MEMCC="3000,/tmp/hyc1234"
> 
> If Unix mode bits are used, that is no different from using a ccache file
> which has the ownership problem described in the web server scenario.

Your proposal for a kernel driver below would have the same ownership problem. 
Unless you're telling me that your driver would allow any user opening the 
device to specify any arbitrary UID to own a particular cache. That seems a bit 
odd to me but so it goes; HPUX also allows anyone to chown files they own to 
anybody else too by default so somebody out there must think it's a good idea. 
 From a security perspective, it's apalling.

 > If
> descriptor inheritance is used, descriptors are not inherited across
> execv which breaks Henry's "admin window" scenario.

Nonsense. Descriptors are only closed if they are explicitly set to Close-on-Exec.

>>> On Aug 22, 2007, at 10:21 AM, Michael B Allen wrote:
>>>> Hi Ken,
>>>>
>>>> I think that the ccache plugin idea is a worthwhile project. Yes, I
>>>> think it would solve Alf's original issue. But by itself it would not
>>>> solve the shared storage or access control issues (access control  
>>>> being
>>>> what I am really interested in).
>>>>
>>>> The only way to ensure that the ccache is truly protected is with a
>>>> kernel extension. I think I would rather invest time into a solid long
>>>> term solution and I think a secure shared storage kernel extensions
>>>> project would be a step in the right direction.
>>>>
>>>> The extension could be quite simple. The caller could open a file that
>>>> and do an ioctl something roughly like:
>>>>
>>>>   int fd = open("/dev/sss0", flags)
>>>>   ioctl(fd, req, "krb5cc[uid=1234,ppid=5678]")
>>>>   FILE *ccachefp = fdopen(fd, mode)
>>>>
>>>> So the kernel extension could be a simple device file implementation
>>>> (this should handle all of the *nix systems). The ioctl data
>>>> "krb5cc[uid=1234,ppid=5678]" indicates the name of the storage and
>>>> some access control parameters. If the storage is created vs opened
>>>> the access control parameters are set. The uid indicates that the  
>>>> named
>>>> ccache is specific to processes with that uid. The ppid indicates that
>>>> only processes with that pid or a descendant of that pid (i.e. the  
>>>> check
>>>> would simply walk up the parent pids of the current process until it
>>>> matched the supplied ppid) should have access to the storage.
>>>>
>>>> Now if there's some young buck out there looking for an excuse to
>>>> experiment with kernel extensions, here's your chance for glory!
>>>>
>>>> Mike
>>> ------------------------------------------------------------------------
>>> The opinions expressed in this message are mine,
>>> not those of Caltech, JPL, NASA, or the US Government.
>>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
>>>
>>>
>>
>> -- 
>>    -- Howard Chu
>>    Chief Architect, Symas Corp.  http://www.symas.com
>>    Director, Highland Sun        http://highlandsun.com/hyc/
>>    Chief Architect, OpenLDAP     http://www.openldap.org/project/
>>
> 
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/