[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 19:49:14 -0700
Howard Chu <hyc@highlandsun.com> wrote:
> 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.
Permissions on the device file would allow anyone to open it. But no
one could read or write to the resulting descriptor until they did an
ioctl. The ioctl would look at the calling process pid and it's parents
to determine if it is granted access to the storage.
> > 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.
True. I don't know what I was thinking.
But using a file backed mapping is still no better than a disk file
ccache. You would have to use an anonymous mapping to protect the storage
from non-decendent processes.
Mike
> >>> 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/
>
--
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/