Re: [PATCH] implement in-kernel keys & keyring management

[David Howells <dhowells@redhat.com>]

Trond Myklebust <trond.myklebust@fys.uio.no> wrote
> >  - Two std keyrings per user: per-user and default-user-session
> 
> So what *is* the reason for the "per-user" and "default-user-session"
> keys?

Well, Linus wants a user keyring. Originally I was going to just include this
in the "search path" for keyring search.

However, it has become obvious that it's necessary to be able to exclude the
user keyring from the search path under certain circumstances, so I thought
why not add it to the session key, so that it is accessible via keyring
nesting.

However, I think it's still necessary to show some separation between the
session and the user keyrings, and unless PAM or something is made use of, you
won't get that if each process uses the user keyring as its session by
default.

It also allows me to add a facility by which a process can duplicate its
session keyring and subscribe to the new one instead, whilst retaining a link
to the real user keyring.

Of course, this is open to negotiation. I'm not entirely convinced I need it,
but it seemed right at the time.

> In a strong authentication model, a setuid process should not normally
> find itself automatically authenticated to a new set of keys.

This only happens when a process subscribed to the root default-user-session
keyring sets the UID to something non-zero. Execution of a SUID binary does
not change the session keyring.

The idea was that non-root users will probably want their own session keyring,
not root's.

I can think of several other ways of dealing with this:

 (*) Let userspace (PAM) determine the session.

 (*) Start with no session keyring set on any process, and only attach a
     process to the default-user-session when someone tries to access their
     session keyring if there isn't one set, or when a setuid() is performed
     (or maybe setsid()?).

 (*) Have an init-specific session keyring as well.

David