Re: Support for other keyrings than logon in fscrypt?

[Eric Biggers <ebiggers3@gmail.com>]

On Wed, Feb 15, 2017 at 11:33:09PM +0100, Richard Weinberger wrote:
> > 
> > I used keyrings because it seemed like it was the "right thing" to do
> > since it's the kernel abstraction.  In fact the use of keyrings has
> > been a monster headache, because their semantics are just... weird,
> > and not a good fit for things like how the VFS cache works, for
> > example.
> > 
> > Among other things, there is no such thing as a globally accessible
> > keyring.  We could set up a per-file system specific keyring, which is
> > attached to the struct superblock, and then define root-only ioctl's
> > to explicitly add and remove keys from that file system specific key
> > ring.
> 
> Yes, I had something like that in mind.
> This would require only minimal changes to fs/crypto/keyinfo.c.
> 
> If you are fine with such a change I'd submit a patch.
> 

This may be reasonable, given that there is no true global keyring (though as
noted, a session keyring can in some cases be used to emulate one).  I also
agree that any ioctl to add global keys would for now need to be root-only.

Note that eventually it would be nice to add key verification.  This could be
done by storing a cryptographically secure hash of the actual master key, or
perhaps a MAC keyed by the master key that also authenticates the rest of the
encryption xattr including the nonce and encryption modes.  The filesystem would
use this to cryptographically enforce that the correct key is provided.  In that
situation, it would theoretically be safe to allow filesystem-level keys to be
added by untrusted users.  Of course, there would still have to be a limited
number of keys allowed per user (maybe tracked in user_struct, like some of the
other limits) to prevent a user from causing a denial of service by adding an
arbitrarily large number of keys.

Also, to support revocation without a full permissions system, the ioctl to add
a key could perhaps also return a randomly generated "revocation token" with a
secure length, e.g. 16+ bytes, which could later be provided to remove/revoke
the key.  (Of course, that's only useful if untrusted users can also add keys;
if only root can, then it's sufficient to simply make removal root-only too.)

Just some thoughts!

Eric