
Ext4 encryption - rubikscube
https://lwn.net/Articles/639427/
======
click170
> 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.

Did this line stand out to anyone else?

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.

Does Full Disk Encryption have this problem as well (mounting a maliciously
modified full disk encrypted filesystem could result in disclosure)?

~~~
TD-Linux
Yes, in all of these cases you can modify the initrd to steal credentials.

~~~
paulfurtado
That's not totally a given anymore with so many UEFI laptops capable of Secure
Boot. They additionally mentioned android as a use case for this which also
generally comes with a locked bootloader among other boot chain security
features.

You can build the kernel as an EFI module (using EFISTUB) and have EFI verify
its signature. Most new laptops do support this and an increasing number of
desktops and servers do too. In this case, some users may be surprised to find
that even though they used ext4's encryption on /, someone can still modify
the inode table since it remains unencrypted (though I could be reading the
article wrong).

------
kijin
According to the comments, the primary benefits of filesystem-level encryption
over full-disk (block-level) encryption are claimed to be:

1) The filesystem can be configured to expose different parts of the tree to
different users, whereas FDE is all-or-nothing.

2) The filesystem can make room for more metadata than a block device, so it
would be easier to implement authenticated encryption.

3) More fine-tuned control over caching.

But are these really significant advantages?

1) Most devices nowadays, including Chromesbooks and Android phones, are only
ever used by one person.

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.

3) Can't this be addressed at a lower level?

~~~
caf
For point 2, you can't just expose a smaller block to the next layer -
everything is designed to work with 512-byte logical blocks. You could
possibly do it if you were willing to sacrifice half your disk space by
pairing every 512-byte data block with a 512-byte authenticator block, but...

...the other issue is that you need a way to atomically update the data block
and authenticator together. This is a similar problem to the "RAID write
hole", and doing this at the block layer requires even more overhead -
something equivalent to RAID write intent bitmaps.

The filesystem, on the other hand, already tends to have a journal, log-
structure or COW rules that allows some form of atomic transactional updates.
The encryption authenticator can piggy-back on this.

~~~
Dylan16807
Well if you use atomic 4K writes to the drive, and expose each one as 7
512-byte blocks to the next layer...

~~~
kijin
That's exactly what I was thinking.

SSDs have fairly large page sizes and erase block sizes, so you're often
reading and writing a lot more than necessary, anyway. A clever implementation
might be able to take advantage of that to scatter the MAC throughout the
drive without too much impact on performance or longevity.

------
pmontra
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.

~~~
cynix
Doesn't this defeat the purpose of encryption? If someone steals your server,
they can just reboot it and get access to everything.

~~~
pmontra
Exactly, that's why the password shouldn't be on the server, but having to
type it in every time is inconvenient. Nothing I've been able to think about
is secure so I was asking. I also understand that any attacker gaining access
to the server while it's running (the usual scenario) gets access to the
unencrypted file system so maybe it doesn't make much sense to encrypt
servers. Still I'm curious.

~~~
teddyh
> _Exactly, that 's why the password shouldn't be on the server, but having to
> type it in every time is inconvenient. Nothing I've been able to think about
> is secure_

That’s what I said to a friend of mine when we had numerous servers with
encrypted disks and frequent power outages requiring us to type in passwords.
He then suggested many different schemes to fix this, each of which I shot
down as being insecure. Then he came up with something which I couldn’t shoot
down, and he made a first proof-of-concept implementation, which is how
Mandos¹ got started. This was many years ago; Mandos has since become
available in Debian and Ubuntu; just do "apt-get install mandos".

① [https://www.recompile.se/mandos](https://www.recompile.se/mandos)

------
throwaway12357
For those who missed it there is a relevant comment by user abatters against
the use of per-directory encryption:

[https://lwn.net/Articles/639766/](https://lwn.net/Articles/639766/)

edit: how can I quote a block of text that preserves newlines?

------
caf
I'm not sure how this is supposed to work in the mobile device (Android /
Chrome OS) scenario.

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.

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?

~~~
pwnna
You can wipe the master key when you suspend. However it will just mean that
there needs to be some unencrypted storage to write down things like incoming
text messages. Caller ID will also not work (or be stored in the unencrypted
storage).

There are ways to do it, but you will lose security/convenience. It all depend
on your threat model and how inconvenient you're willing to make your phone.

~~~
caf
If your text messages and contacts have to be stored in unencrypted storage,
then what exactly are we protecting here - your 2048 high score?

------
edwintorok
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.

------
wfunction
Could someone please give or link to a comparison of Ext4 encryption and NTFS
encryption?

------
angelortega
Don't miss the comments in the linked page for more insightful information.

