Ext4 encryption [LWN.net]

Ext4 encryption

Posted Apr 9, 2015 22:15 UTC (Thu) by reubenhwk (guest, #75803)
In reply to: Ext4 encryption by meskio
Parent article: Ext4 encryption

I didn't catch whether or not it encrypts xattrs. I also missed a bit about modification of the encrypted data. Are they not using MACs to ensure the data hasn't been changed?

to post comments

Ext4 encryption

Posted Apr 10, 2015 22:04 UTC (Fri) by mhalcrow (guest, #17371) [Link] (1 responses)

Encryption with authentication should happen and is on my road map. But it's also hard to get right, and we don't have the facilities in place yet to give us per-block metadata with transactional semantics. I think we'll have it before too long though. Jonathan was careful to discuss the adversarial model in his writeup, and that's important to keep in mind when making a decision about whether or how to use this feature.

Ext4 encryption

Posted Apr 11, 2015 16:30 UTC (Sat) by Trou.fr (subscriber, #26289) [Link]

Ah, thank you for the update. I must admit I don't really see much to gain by using ext4 encryption vs dm-crypt if you don't get authentication.

I really look forward for a version with auth, it would be quite useful for homedirs.

Ext4 encryption

Posted May 20, 2018 11:23 UTC (Sun) by e4crypt (guest, #124524) [Link]

I didn't catch whether or not it encrypts xattrs.

It doesn't. Extended attributes are plain-text. Even if there is no key in the keyring and the file contents are not accessible, everyone can still read xattrs.

This is a major security hole on personal devices. Some very popular applications set extended attributes on files (even though mostly this information remains untouched). The most notable culprits are: Chrome/chromium and Wget.

# truncate -s 2G storage
# mkfs.ext4 storage
# tune2fs -O encrypt storage
# mkdir mountpoint
# mount storage mountpoint
# cd mountpoint
# mkdir protected
# e4crypt add_key protected
# cd protected
# wget https://static.lwn.net/images/logo/barepenguin-70.png
# getfattr -d barepenguin-70.png
> # file: barepenguin-70.png
> user.xdg.origin.url="https://elitewow.com.br/browse?q=zaylqKtyZ5GjrZOnopNhna7PkJ_H2GefncSdnKxfo6jMp2Camaqd0pWnmaiinmBoZ4_Sn8k"
# cd ../..
# umount mountpoint
# e4crypt new_session
# mount storage mountpoint
# getfattr -d mountpoint/protected/w6W9jZ+I2d62uybxftwuHt4,M3N
> # file: mountpoint/protected/w6W9jZ+I2d62uybxftwuHt4,M3N
> user.xdg.origin.url="https://elitewow.com.br/browse?q=zaylqKtyZ5GjrZOnopNhna7PkJ_H2GefncSdnKxfo6jMp2Camaqd0pWnmaiinmBoZ4_Sn8k"

To protect against such an obvious leak, I suggest the following workaround. Obviously, it could be much better if extended attributes were stored encrypted along with file contents.

Mount a filesystem with an option "nouser_xattr" set. This will protect against "accidental" setting of extended attributes by applications. Note the downside of this approach: the option can only be set per mountpoint, meaning that user extended attributes will be disabled across the filesystem, not only in protected paths.

# mount -o nouser_xattr storage mountpoint

But for the time being, ext4 filesystem encryption support seems to be more well-suited to protect mail spool directories and proprietary software on Git shared hosting. It is a bit premature to speak about desktop/end-user readiness.

May 2018. Tested with kernel 4.14.40 and e2fsprogs 1.44.1.