[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 <email@example.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 firstname.lastname@example.org
> -- 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