GSSAPI Proxy initiative

[Tom Yu]

Trond Myklebust <Trond.Myklebust at netapp.com> writes:

> Linux already has per-user, per-process and per-thread keyrings which
> offer a high security storage solution for keys. The problem with those
> is that they are difficult to use in an asynchronous context when the
> original user's process/thread context is no longer available to us.
>
> Ideally, though, that's what we'd like to see used.

Perhaps I misunderstand what you're proposing to use the keyring for,
but I would like to clarify a few things.

Opaque key storage is probably not the right abstraction level to
represent the kind of privilege separation we want here.  It's clearly
already possible to use the Linux keyring, TPM, smart cards, etc. to
achieve opaque key storage.

One of the original goals is privilege separation.  The GSS proxy can
allow an unprivileged process to perform specific restricted
operations with key material such as a host key, instead of the mostly
unrestricted encryption, decryption, etc. access that you would get
with an opaque or unextractable key model.  The proxy could limit the
client's use of the key to gss_accept_sec_context(), without allowing
the sort of generalized cryptographic operations that would allow the
client to, say, forge a PAC signature.