Re: Support for other keyrings than logon in fscrypt?

Re: Support for other keyrings than logon in fscrypt?

[Richard Weinberger]

CC'ing linux-fsdevel ;-\

Am 14.02.2017 um 11:38 schrieb Richard Weinberger:
> Hi!
> 
> 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?
> 
> Thanks,
> //richard
> 

Re: Support for other keyrings than logon in fscrypt?

[Eric Biggers]

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

Re: Support for other keyrings than logon in fscrypt?

[Richard Weinberger]

Eric,

Am 15.02.2017 um 07:27 schrieb Eric Biggers:
> 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.

I agree.

> 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.

In my case root would install a key (for the whole filesystem) and later
the same key needs to be available to *all* users, *forever*.

My fear is that some smart userspace component could kill the key at some time.
systemd by creating new session, I'm looking at you.
Just kidding. ;)

Thanks,
//richard

Re: Support for other keyrings than logon in fscrypt?

[Theodore Ts'o]

On Tue, Feb 14, 2017 at 11:51:31AM +0100, Richard Weinberger wrote:
> CC'ing linux-fsdevel ;-\
> 
> Am 14.02.2017 um 11:38 schrieb Richard Weinberger:
> > Hi!
> > 
> > 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 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.

Perhaps we should have gone down this route initially; it would have
simplified a bunch of things, even for the Android/ChromeOS use case.

The problem is that it's non-ideal from the desktop use case, since it
means you need to root to add and remove keys.  And in the case of key
removal, even with a setuid binary, it's not clear when a user should
be allowed to remove a key globally.  Even if the user can prove that
it owns the key, perhaps that key is in use by another user?

But yes, in the case of supportting a globally accessible key, we
would need to put that in initramfs.  This being said, however, if you
*are* using a globally accessible key, using encryption at the
dm-crypt layer makes a **ton** more sense.  I know this doesn't work
for ubifs because it's not using a block device, but if you *are*
using a global key that is accessible to all, and installing it at
boot time, you might as well encrypt the metadata blocks as well, at
which point it's not clear the fscrypt model makes sense for you at
all.

Cheers,

     	        	       	     	     - Ted

Re: Support for other keyrings than logon in fscrypt?

[Richard Weinberger]

Adding David Howells into the loop.

Am 15.02.2017 um 16:55 schrieb Theodore Ts'o:
> On Tue, Feb 14, 2017 at 11:51:31AM +0100, Richard Weinberger wrote:
>> CC'ing linux-fsdevel ;-\
>>
>> Am 14.02.2017 um 11:38 schrieb Richard Weinberger:
>>> Hi!
>>>
>>> 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 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.

> Perhaps we should have gone down this route initially; it would have
> simplified a bunch of things, even for the Android/ChromeOS use case.
> 
> The problem is that it's non-ideal from the desktop use case, since it
> means you need to root to add and remove keys.  And in the case of key
> removal, even with a setuid binary, it's not clear when a user should
> be allowed to remove a key globally.  Even if the user can prove that
> it owns the key, perhaps that key is in use by another user?
> 
> But yes, in the case of supportting a globally accessible key, we
> would need to put that in initramfs.  This being said, however, if you
> *are* using a globally accessible key, using encryption at the
> dm-crypt layer makes a **ton** more sense.  I know this doesn't work
> for ubifs because it's not using a block device, but if you *are*
> using a global key that is accessible to all, and installing it at
> boot time, you might as well encrypt the metadata blocks as well, at
> which point it's not clear the fscrypt model makes sense for you at
> all.

I fully agree to these security concerns. But the kernel offers the
mechanism and user(space) the policy. If users want UBIFS to encrypt
all files with the same key, it should be supported.

Setting the key in initramfs is what I do currently, it works fine
as soon no other user logs in. In that case I need a modified version of
pam_keyinit that does not reset my session keyring but links the filesystem
encryption key into the current keyring.
That is very error prone IMHO.
Embedded folks tend to mess up their userspace. ;-)

Thanks,
//richard

Re: Support for other keyrings than logon in fscrypt?

[Theodore Ts'o]

On Tue, Feb 14, 2017 at 10:27:28PM -0800, Eric Biggers wrote:
> 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.
>

Nope, Android uses a session keyring, and takes special care to make
sure all user processes belong to that session.  There is,
unfortunately, no such thing as a global keyring.  Subsystems like
which need global access to keying material, such as dm-crypt, don't
use the keyring abstraction.

						- Ted

Re: Support for other keyrings than logon in fscrypt?

[Eric Biggers]

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