[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MEMORY credential cache interop between Heimdal and MIT?
On Aug 15, 2007, at 18:33, Michael B Allen wrote:
>> MEMORY ccaches are per process. Are you really attempting to mix
>> 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
> Heimdal. Other libraries that can initiate Kerberos authentication
> 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
> 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
> 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