Re: Support for other keyrings than logon in fscrypt?

[Eric Biggers <ebiggers3@gmail.com>]

Hi Richard,

On Tue, Feb 14, 2017 at 11:51:31AM +0100, Richard Weinberger wrote:
> AFACT fscrypt was designed for the Android/ChromeOS use-case to encrypt a home directory.
> For this case using keys of type logon makes perfectly sense.
> But there are cases where other types would be useful.
> Please consider the case where the whole filesystem is encrypted and an initramfs loads
> the encryption master key. Here a logon key is not suitable since different users might need
> it.
> 
> I suggest adding support for different types to fscrypt_get_crypt_info().
> I.e. such that a filesystem can indicate in ->s_cop that a "global" key ring
> should be used.
> 
> What do you think?

I think you may be confusing keys and keyrings.  "logon" is a type of key, not a
type of keyring.  The semantics of a "logon" key are that it can be created and
updated by userspace, but cannot be read by userspace.  (See
Documentation/security/keys.txt.)  Despite the name it does not need to be tied
to an actual user "logging in" per se, and you can add a "logon" key to any
keyring, either one of the special ones like a session keyring, or to a manually
created one.

Also, session keyrings do not need to be tied to other concepts of a "session";
a process can simply set one up, and it gets inherited by children.  So it would
be possible for init to insert the key into its session keyring, and then all
processes would inherit it, unless they explicitly replace it.

If I'm not mistaken, Android actually uses a global keyring quite similarly to
that.  I think the only real difference is that a privileged process on Android
adds and removes keys as users log in and out, whereas you'll need to add a key
at init time only.

Eric