Re: MEMORY credential cache interop between Heimdal and MIT?

[Howard Chu <hyc@highlandsun.com>]

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"

> 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/