> The developers note, though, that if an attacker can make changes to an encrypted filesystem that is subsequently mounted by the user, all bets are off.<p>Did this line stand out to anyone else?<p>I would expect modification of an encrypted directory to cause the loss of any modified files, but I'm surprised at the specific wording of that statement. From that, I'm reading that it could be possible to modify an encrypted directory so as to cause key or plaintext content leakage if the directory is accessed again or the volume is re-mounted.<p>Does Full Disk Encryption have this problem as well (mounting a maliciously modified full disk encrypted filesystem could result in disclosure)?
According to the comments, the primary benefits of filesystem-level encryption over full-disk (block-level) encryption are claimed to be:<p>1) The filesystem can be configured to expose different parts of the tree to different users, whereas FDE is all-or-nothing.<p>2) The filesystem can make room for more metadata than a block device, so it would be easier to implement authenticated encryption.<p>3) More fine-tuned control over caching.<p>But are these really significant advantages?<p>1) Most devices nowadays, including Chromesbooks and Android phones, are only ever used by one person.<p>2) We could modify dm-crypt to set aside a certain amount of space for MAC, and just expose a smaller block device to the next layer. Besides, the proposed changes to ext4 don't use authenticated encryption, either.<p>3) Can't this be addressed at a lower level?
A related question: what's the best practice to encrypt the FS of a server and allow unattended reboots? One doesn't want to have to type in a password at each reboot (no unattended reboots and impractical for large number of servers) but the password can't be left attached to the server. So how is it done, if it is done? Thanks.
For those who missed it there is a relevant comment by user abatters against the use of per-directory encryption:<p><a href="https://lwn.net/Articles/639766/" rel="nofollow">https://lwn.net/Articles/639766/</a><p>edit: how can I quote a block of text that preserves newlines?
I'm not sure how this is supposed to work in the mobile device (Android / Chrome OS) scenario.<p>These devices are typically on (but suspended) when they're lost. If this means the master key is still in memory, then the attacker has it.<p>If, on the other hand, the master key is wiped when the device suspends and is reloaded when you unlock the device, how does your SMS application write your messages (that come in while the device is suspended) to disk? How does the phone lookup your contacts to display the incoming caller name if the device was suspended when the call came in?
I noticed that ecryptfs + ext4 doesn't support sparse files efficiently (it takes a long time to write to a large sparse file, as if it actually writes/encrypts all the zeroes).
Having encryption directly in ext4 should solve that, but I haven't tested the patchset yet.