Re: MEMORY credential cache interop between Heimdal and MIT?

[Michael B Allen <miallen@ioplex.com>]

[removing some addresses that have been inactive]

On Wed, 22 Aug 2007 08:52:06 -0400
Ken Raeburn <raeburn@MIT.EDU> wrote:

> On Aug 16, 2007, at 16:51, Michael B Allen wrote:
> > On Thu, 16 Aug 2007 15:03:24 -0400
> > Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
> >
> >> Michael:
> >>
> >> Have you examined the krb5_cc_xxx API that both MIT and Heimdal  
> >> implement?
> >>
> >> If krb5_cc_register() was exported, would that satisfy your  
> >> requirement?
> >>
> >> It would permit you to add any credential cache implementation of  
> >> your
> >> choice to the library at run-time.
> >
> > Hi Jeffrey,
> >
> > That wouldn't work. The krb5_cc_register function would only register
> > cc ops with the implementation with which you're linked [1]. So if
> > your program is linked with Heimdal and it called a cURL library that
> > was linked with MIT, the krb5_cc_register call will have no effect
> > on the ccache code used by cURL. And even if you could call the other
> > implementation's krb5_cc_register using some crazy dlopen trickery the
> > internal structures are not the same.
> 
> The idea I had (which I guess I didn't outline well) was to either  
> use dlopen so you can independently access both implementations, or  
> create multiple shared objects, for example:
> 
> obj1.so
>    implements a cache
>    links against obj2.so and obj3.so
>    library init function calls register_cache_with_mit,  
> register_cache_with_heimdal
> obj2.so
>    links against MIT code
>    implements register_cache_with_mit
> obj3.so
>    links against Heimdal code
>    implements register_cache_with_heimdal
> 
> Then set LD_PRELOAD=/path/to/obj1.so, or link the application against  
> it.  Unless the dynamic linker loads multiple copies of the  
> libraries, this ought to get you a shared credential cache between  
> the implementations for that process.  The core implementation can  
> define its own data structures, and the methods for each  
> implementation can do the translation.
> 
> However you do it, you'd probably wind up wanting to compile multiple  
> object files anyways, to avoid confusion between the MIT and Heimdal  
> type names and such.  Though you could simplify it from the above,  
> merging either obj2.so or obj3.so into obj1.so, for example.  Or  
> linking a non-shared obj1.o directly into the application instead of  
> as a shared library object.  Et cetera....
> 
> Kind of ugly, but it would get the originally requested functionality  
> with today's released libraries.

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

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