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
