Re: [Keyrings] [PATCH] Keys: Add LSM hooks for key management

[David Howells]

James Morris <jmorris@xxxxxxxxx> wrote:

> What about a per process /proc/pid/keys, which contains keyrings and keys, 
> which can be opened, closed, use xattrs for any special access control 
> etc. ?

Not a good idea; especially not in /proc. Why are people fixated on using the
VFS interface when it doesn't fit? Making things into filesystems isn't
necessarily a good thing.

However, /proc/pid/xxx files for the ID of each keyring would be a good idea;
I did have a patch to do that once, but it seems have got lost.

> > Should I expand the permissions mask to include a setattr?
> 
> Possibly for setperm and chown.

For setperm?

> > > All users of key_permission() need to propagate the error code from the 
> > > LSM back to the user.
> > 
> > Really? Why?
> 
> Because the LSM has final say on the error code returned to the caller.  
> If the LSM runs out of memory, for example, it's silly to return -EACCES.
> 
> > Note that the fact that key_permission() fails for a key is sometimes
> > ignored, such as when I'm doing a search and one potentially matching key
> > fails, but a subsequent matching key passes.
> 
> Ok, that sounds like an internal issue to be resolved, ensuring that if 
> you are returning to the caller, the LSM's error code is returned.

But which LSM error code?

Let me explain what I mean:

 (1) When the key management code searches for a key (keyring_search_aux) it
     firstly calls key_permission(SEARCH) on the keyring it's starting with,
     if this denies permission, it doesn't search further.

 (2) It considers all the non-keyring keys within that keyring and, if any key
     matches the criteria specified, calls key_permission(SEARCH) on it to see
     if the key is allowed to be found. If it is, that key is returned; if
     not, the search continues, and the error code is retained if of higher
     priority than the one currently set.

 (3) It then considers all the keyring-type keys in the keyring it's currently
     searching. It calls key_permission(SEARCH) on each keyring, and if this
     grants permission, it recurses, executing steps (2) and (3) on that
     keyring.

The process stops immediately a valid key is found with permission granted to
use it. Any error from a previous match attempt is discarded and the key is
returned.

When search_process_keyrings() is invoked, it performs the following searches
until one succeeds:

 (1) If extant, the process's thread keyring is searched.

 (2) If extant, the process's process keyring is searched.

 (3) The process's session keyring is searched.

 (4) If the process has a request_key() authorisation key in its session
     keyring then:

     (a) If extant, the calling process's thread keyring is searched.

     (b) If extant, the calling process's process keyring is searched.

     (c) The calling process's session keyring is searched.

The moment one succeeds, all pending errors are discarded and the found key is
returned.

Only if all these fail does the whole thing fail with the highest priority
error. Note that several errors may have come from LSM.

The error priority should be:

	EKEYREVOKED > EKEYEXPIRED > ENOKEY

EACCES/EPERM should only really be returned on a direct keyring search where
the basal keyring doesn't have Search permission.

The fact that I couldn't find a key because I didn't have permission to find
it probably shouldn't cause an immediate abort of the search with an error, or
any error other than ENOKEY/EKEYREVOKED/EKEYEXPIRED, unless I'm not permitted
to request a new key.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/