4 ms·

There was also a series of issues found by with the encryption used by ecryptfs: https://defuse.ca/audits/ecryptfs.htm https://defuse.ca/audits/ecryptfs.htm T

There was also a series of issues found by with the encryption used by ecryptfs: https://defuse.ca/audits/ecryptfs.htm https://defuse.ca/audits/ecryptfs.htm The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.

h4b4n3r0 8y ago
There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.
- mjevans 8y ago
  For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes. Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway. Remote interaction is then required to bring the VMs on that system up.
  - Spivak 8y ago
    They could not have done that to the bootloader because of SecureBoot.
    - bobpaul 8y ago
      With secureboot on Linux you can secure as much or as little as you want. On my system, grub isn't even safe, only the shim that load grub is secure. But I could set it up so the kernel is secure, have the kernel only load verified initrd, and then have the initrd check the root filesystem. I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.
- shittyadmin 8y ago
  On Debian-based systems including Ubuntu, they offer an initrd based Dropbear (lightweight SSH server) which can be used to connect and authenticate. Involved a bit of custom scripting last I checked though, but a possible solution if that's a requirement for you.
- cbhl 8y ago
  You could put a daemon on the initramfs (say, ssh) that allows you to remotely provide a key/password for decrypting the disk. This would certainly be more work to set up than vanilla full-disk encryption, though.
MikeHalcrow 8y ago
Author of eCryptfs and EXT4 encryption chiming in. "Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact. That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast. Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.
- shittyadmin 8y ago
  Ah, you're right, I had it confused with a similar analysis on EncFS which had more significantly damaging findings. https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.
  - colint 8y ago
    According to Michael Halcrow's LinkedIn [1], he was heavily involved on the EXT4 encryption: "I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android." [1] https://www.linkedin.com/in/michael-halcrow-1880601 https://www.linkedin.com/in/michael-halcrow-1880601

h4b4n3r0 8y ago

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

mjevans 8y ago
For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes. Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway. Remote interaction is then required to bring the VMs on that system up.
- Spivak 8y ago
  They could not have done that to the bootloader because of SecureBoot.
  - bobpaul 8y ago
    With secureboot on Linux you can secure as much or as little as you want. On my system, grub isn't even safe, only the shim that load grub is secure. But I could set it up so the kernel is secure, have the kernel only load verified initrd, and then have the initrd check the root filesystem. I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.
shittyadmin 8y ago
On Debian-based systems including Ubuntu, they offer an initrd based Dropbear (lightweight SSH server) which can be used to connect and authenticate. Involved a bit of custom scripting last I checked though, but a possible solution if that's a requirement for you.
cbhl 8y ago
You could put a daemon on the initramfs (say, ssh) that allows you to remotely provide a key/password for decrypting the disk. This would certainly be more work to set up than vanilla full-disk encryption, though.

MikeHalcrow 8y ago

Author of eCryptfs and EXT4 encryption chiming in. "Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact. That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast. Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.

shittyadmin 8y ago
Ah, you're right, I had it confused with a similar analysis on EncFS which had more significantly damaging findings. https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.
- colint 8y ago
  According to Michael Halcrow's LinkedIn [1], he was heavily involved on the EXT4 encryption: "I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android." [1] https://www.linkedin.com/in/michael-halcrow-1880601 https://www.linkedin.com/in/michael-halcrow-1880601