[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MEMORY credential cache interop between Heimdal and MIT?



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. If
descriptor inheritance is used, descriptors are not inherited across
execv which breaks Henry's "admin window" scenario.

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


-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/