ccache using linux Keyrings

[Nicolas Williams]

On Fri, Apr 14, 2006 at 01:37:33AM -0700, Frank Cusack wrote:
> On April 13, 2006 9:37:47 AM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> >On Wed, Apr 12, 2006 at 06:42:31PM -0700, Frank Cusack wrote:
> >>On April 12, 2006 6:37:25 PM -0700 Frank Cusack <fcusack at fcusack.com> 
> >>wrote:
> >>> Sorry for my late entry into this thread, and more importantly, that I
> >>> haven't read the entire thread (I missed the beginning).
> >>>
> >>> What is the *point* of using a kernel keyring?
> >
> >It's like a PAG.
> 
> Not without associated handling, though.  Just having a keyring that
> isn't referenced except by userland apps is basically shared memory.
> Perhaps with finer-grained access control.

With different inheritance semantics and more observable from peer
processes.  I.e., it's not like shared memory at all.

> >>eh, I just thought of one, after reviewing some older messages in this
> >>thread.  Can gssd be eliminated?
> >
> >Probably not.  See the "Solaris ssh pam_krb" thread on kerberos at mit.edu
> >two weeks ago.
> 
> OK, I looked at that thread (whew) and from that I don't see why gssd
> would have to stay around.

Because you're not going to want to keep arbitrarily large amounts of
crap in your keyring, because you're not going to want to bring into the
kernel every cryptographic protocol or mechanism just because.

Do you want IKE in the kernel?  But surely you do want ESP/AH in the
kernel.  The kgssapi/gssd split achieves the moral equivalent of the IKE
vs. ESP/AH split for the GSS-API: context token handling and security
context establishment happens in user-land, while session protection
(per-msg tokens) is handled in kernel-land.

Because the GSS-API is pluggable and you might have really complex
mechanisms, like ones that do PKIX certificate validation (that sounds
like a fun thing to do in kernel-land!  Not :) :)

> >You can't avoid some upcalls in general without putting too much
> >complexity into the kernel.  Examples abound.  E.g., do you want IKE
> >exchanges triggered by outgoing packets to be done in-kernel?
> 
> Not in general, but isn't gssd specific to nfs/gss?  But that does
> remind me of one issue where gssd couldn't go away: it might have to
> obtain a new session ticket.  You don't want that in the kernel.

See?

> OK, given that gssd can't go away, I don't see the point of using the
> Linux kernel keyring.  Data can be got out of it by the proper uid just
> as data can be gotten out of FILE: ccaches.  Yes?

Thank you :)  The Linux keyring is really like a coordination system
here, much like PAGs, much as described in that other thread.  You
really don't need to store tickets in the keyring.

Nico
--