Re: MEMORY credential cache interop between Heimdal and MIT?

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

On Wed, 15 Aug 2007 21:26:45 -0400
Ken Raeburn <raeburn@MIT.EDU> wrote:

> On Aug 15, 2007, at 18:33, Michael B Allen wrote:
> >> MEMORY ccaches are per process.  Are you really attempting to mix  
> >> both
> >> Heimdal and MIT kerberos within the same process?
> >
> > Absolutely. I didn't start this thread.
> >
> > Imagine a web server DSO module that implements HTTP authentication  
> > using
> > Heimdal. Other libraries that can initiate Kerberos authentication  
> > such
> > as PostgreSQL, cURL and LDAP are may be linked with MIT Kerberos. So
> > how does one write a web script that uses the Heimdal authenticated  
> > web
> > client's credential to authenticate with another tier using one of the
> > modules linked with MIT Kerberos? If you put the delegated credential
> > into a ccache file owned by the web server, worker processes have  
> > access
> > to all credentials which is a potential security hazard. It would be
> > superior to place credentials into storage that is properly protected
> > by the OS (e.g. by process group, by secret key, by something in the
> > users security context, etc).
> 
> This doesn't sound to me all that different from the lossage you get  
> on Windows if you link DLLs against different versions of the C  
> runtime, and then expect them to be able to share C runtime data like  
> the malloc free pool.  It sounds great, but it's not likely to work.   
> It's hard to implement, especially if you're going to let the  
> implementors manage and change their internal data formats.  You  
> might be able to export credentials from one implementation in wire  
> format and import into another, but I haven't checked.
> 
> We could conceivably create a new ccache type where the name includes  
> a representation of the address in memory where data is stored in  
> some portable format known to both implementations.  (How you  
> validate the value, so as not to crash when started with a bad  
> environment variable setting, while handling the possibility that it  
> was created outside the control of your implementation, is an  
> interesting question.)  However, that's not the current MEMORY: cache.
> 
> As for the OS providing secure storage available only to the right  
> processes (for some definition of "right processes"), there is the  
> Linux in-kernel keychain support, for example.  But even using in- 
> memory credentials won't protect you from one compromised worker  
> process attaching another process under ptrace and extracting  
> credentials (or forcing it to make some OS call to retrieve  
> credentials).

Well I recognised a problem and I'm glad to see that I'm not the only
one but I admit do not have an implementation in mind. However, as a
programmer I can make a few observations.

The problem of a secure credential store can be separated into a few
independent concepts.

 1. How storage is acquired is independent from the format of it's content
    [1].
 2. How storage is acquired is independent from the access control logic
    used to protect it.
 3. The format of storage content is independent from the access control
    logic used to protect it.

That divides the problem into three parts which is considerably easier.

Storage implementations might be based on one of the following:

 o mmap(MAP_ANON)
 o Linux in-kernel keychain support
 o CCAPI on OSX or Windows 
 o Windows LSA Routines
 o Disk file

Note that these may not guarantee a complete implementation. Using
mmap will not allow spawned processes (as opposed to forked) to access
credentials that the access control logic would otherwise grant access
to. Using a disk file for Kerberos credentials would effectively be a
stub implementation that just called existing ccache routines. But the
point is that the storage implementation has been parameterized.

Access control implementations might be based on one of the following:

 o Process ID based logic
 o Windows ACL
 o UNIX file access control based in uid
 o Environment variable "secret" a la ssh-agent

Again, you might not get a bullet proof implementation. An implementation
might use an environment variable set when a login shell was created
to pass a "secret" to spawned processes. Anyone with knowledge of the
secret is granted access to the credential store.

Formats of object in storage is specific to the applications using it.
For Kerberos it seems a credential format exists. The ccache file format
may not be officially standardized but it is understood by both Heimdal
and MIT.

Mike

[1] If CCAPI or the Windows LSA routines are used as pass-through
implementations then storage is not independent of format but of course
the format of credentials is moot if they have already been decoded.