Re: MEMORY credential cache interop between Heimdal and MIT?

[Ken Raeburn <raeburn@MIT.EDU>]

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).

Ken