TL;DR summary: * For single user systems, use LUKS / dm-crypt.
* For multi-user systems, file system level encryption may make sense, but a lot of the tools necessary to do user-friendly key management for a traditional Unix desktop or server have not been implemented yet. Ext4 encryption is basically a superior version of ecryptfs. * There are limitations to ext4 encryption as it is currently implemented. If someone has lots of free time or has a commercial/product reasons to extend ext4 in general or ext4 encryption specifically, please talk to me. I'm happy to help people with designs, especially if they are then willing to contribute resources to get the job done. On Sun, Jun 25, 2017 at 01:01:58PM +0200, Philipp Kern wrote: > > To replace LUKS as an FDE mode we'd first need support in > initramfs-tools to load a key into the kernel's keyring on boot. You should **not** use ext4 encryption as a replacement for full disk encryption. If you want full disk encryption, you should be using dm-crypt. Ext4 encryption is useful if you don't want to encrypt the entire disk with a single key --- either for performance reasons (e.g., you're running on an older Intel CPU which doesn't have AES acceleration), or you want to have different portions of the disks encrypted with different keys, which is the case for Chrome and Android. In the case of Android, different users on a tablet, or your work profile and your personal profile each use different keys. This allows you to remove a user, or when you leave your job for a different employer, allows the work profile to be removed --- without having to wipe the entire device. But from a security perspective, dm-crypt is more secure because all of the file system metadata (e.g., the file size of individual inodes, including encrypted files) are encrypted. This is one of the advantages of block-level encryption versus encryption at the file system level. > But in general ext4 fs-level encryption is "weird" in that the > encryption secret is stored in the login keyring. That makes sense in > the Android world for which it was designed but complicates matters > somewhat on a plain Linux system and has "interesting" behavior > depending if the file you're trying to access is already loaded into the > page cache or not. (As there's a secret you need to have activated in > addition to fs-level permission bits, which are actually separate.) I > think something like pam_e4crypt for the encryption of the user's home > directory would make more sense to support. Yes, or if you want to have a ~/Private directory which is encrypted, and everything else is left unencrypted. You should think of ext4 encryption as being a better version of ecryptfs, not of LUKS. Both have their place, but for most users whose systems are single user laptops or desktops, LUKS really is the better choice. It's also true some of the userspace utilities to allow ext4 encryption to be used on a desktop aren't yet fully developed. I had some conversations with some folks at Canonical to see if they would be interested in implementing the userspace support for traditional Unix systems (as opposed to for Android and Chrome OS) but that was before the big reorg at Canonical and I don't know if they are still signed up to do that work. > I think that nested policies aren't actually supported. I'm also unsure > if setting the policy at the root inode works or not. No to both. There are some tricky security issues with the first, and if someone is really interested I can talk about some of the ideas we've had about how to solve them. We haven't had a product reason to implement it, and I haven't had the time to implement cool technologies just because it's cool for quite some time now. These days I tend to accumulate designs for cool technologies, and then see if I can find a product manager who really wants the feature and who can fund the headcount necessary to do the work, and then give them the design doc. (Even if the product manager works for a different company than my current employer; that's one of the beauties of open source. :-) As for setting the policy at the root inode, this would require doing some extra work in the kernel and e2fsprogs to deal with the lost+found inode. So it added extra complexity, and we had no product reason to support it, so we punted on that idea. > (And I tried to confirm both questions, but encryption didn't work > with loop filesystems because of the blocksize, unfortunately.) Well, you can make it work with a loop file system but for small file systems, mke2fs defaults to a 1k block file system to make the file system conserve space. You can work around this problem by creating a much larger loop file system, or specifying -b 4096 to mke2fs. But that's neither here nor there. - Ted