ccache using linux Keyrings

[Nicolas Williams]

On Wed, Apr 19, 2006 at 01:55:35AM -0700, Frank Cusack wrote:
> Having glanced at it, it seems like a good place to store krb5 creds.  I
> have a question.

I don't think it's a good idea to put Tickets and session keys in the
kernel.

Note: I didn't say it isn't a good idea to use tokens to protect Ticket
      session keys from users.  More on that below.

> Currently, if an nfs service ticket expires, gssd tries to obtain a new
> one using a (hopefully) available TGT.  If a process acquired a new session
> specific nfs cred (ie, stored a cred in a new session keyring for nfs to
> find), how should gssd renew this ticket?  The session specific ticket may
> be for a different principal than the TGT available to gssd.  Consider:
> 
>  sudo ls
>    - sudo creates a new session keyring (via PAM)
>    - user creds go into session keyring
>    - root user can access user's files
>    - ticket expires
>    - gssd upcall for user root, which is the wrong user

Why would you have gssd in the picture if the Tickets are in the kernel?  :)
To do the KDC exchange work?  To build Authenticators?

Anyways, as I understand it Linux keyrings are just like PAGs with data
buckets bolted on.  So it may be useful to look at this from the AFS PAG
perspective:

 - kgssapi would tell gssd the {uid, PAG} of the caller
 - gssd would use the caller's {uid, PAG} to find a Ticket and session
   key and...
 - ...would not find any such valid Tickets (since you say they're
   expired), or TGTs to acquire fresh ones with, thus it will fail the
   GSS_Init_sec_context() call, which...
 - ...will lead to the caller hanging or returning an error from the
   relevant syscall (or some signal, if in a page fault -- hopefully it
   will only hang in page fault cases), pick the semantics you prefer.

> 1) note that this doesn't work today -- sudo ls uses root creds not user 
> creds,
>   but the behavior above is something I'd like

In AFS this does work, because AFS has PAGs, or makes them up out of
supplementary groups (which happens to suffice for AFS).

> 2) it isn't clear to me if root can read user's keys/keyrings, if so than
>   sudo doesn't need to create a new session keyring

All-privileged root could certainly be counted on to be able to do so.

And, BTW, that's the default behaviour in AFS: su (and SUDO) don't
setpag(), so the resulting processes share the same network credentials
as the user.

This relies on a fundamental property of PAGs: you have to take explicit
action to change a process' PAG, otherwise its children inherit the PAG
and the PAG does not change across setuid() and friends.

Of course, that a process has a given PAG doesn't imply it has access to
all credentials associated with that PAG -- other access controls may
apply.

I'm under the impression that the same applies to Linux keyrings.

> 3) this might argue for tgt in the keyring -- not to be used by the kernel
>   itself but just as storage so (eg) upcall to gssd can pass the correct tgt

No, this doesn't argue for that.  Neither does Ticket/ccache size.

Nothing argues for this.  Normally you want to protect a user's ccache
from other users.  Perhaps you want to protect a user's ccache from the
user himself, but for this it suffices (almost; see below) to protect
the associated Ticket session keys -- i.e. store them in a token, or
encrypt them with a key stored in a token and do the Authenticator
encryption in the token (the token might be implemented in kernel-side
SW).

There's no need to store an unbounded number of tickets (of effectively
unbounded size) in the kernel; even if you make it a fixed-sized table
or array and use LRU/LFU to keep its size down it still doesn't make
sense.  There's no need to store even a single TGT.

Protecting Ticket session keys from users is potentially desirable.
Though if you're using PA-ENC-TIMESTAMP (or no pre-auth) then you also
have to protect the client<->KDC traffic, else users can recover their
session keys all on their own.

> Maybe this kind of thing has already been discussed in this thread or AFS
> threads elsewhere.  Sorry to come in late and uninformed.

It has.  But this is an excellent chance to repeat/expand on my argument
against storing Tickets kernel-side.

Nico
--