Re: Support for other keyrings than logon in fscrypt?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux