4 ms·

On the contrary, Ubuntu 18.04 dropped the home directory encryption entirely and now only supports full disk encryption.

ronjouch 8y ago
Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base_system_changes_since_16.04_LTS https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base... > "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."
- shittyadmin 8y ago
  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
- StavrosK 8y ago
  Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.
  - Jedd 8y ago
    > Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience. a) This hasn't ceased to work for your desktop - you can continue to do this through the upgrade cycle, as it would only affect new installs (safely converting native fs to dmcrypt isn't possible, AFAIK) b) during an installation you could eschew FDE and opt for a PV, as I do, that you put your selected, secure LV's onto. I use Debian in preference to Ubuntu, but I'm sure they're materially identical in this case -- two physical partitions -- /boot and not-boot. /boot isn't encrypted in my case, but /, and /home (and a couple of others, though not swap of course) are LVM2 volumes sitting on top of the encrypted 'rest of the disk' partition. If you have /home only with noauto option in fstab , pointing to a an LV on the crypted partition, you could continue to do what you're doing, with the same reduced security confidence.
  - Rondom 8y ago
    Debian and Ubuntu allow running Dropbear in initramfs to prompt for the FDE password
    - StavrosK 8y ago
      That's fantastic to know, thank you. Do you know if it's complicated to set up?
unhammer 8y ago
Though unfortunately if you want to dual-boot, you have to manually set up the encryption :/ As in https://askubuntu.com/a/293029/25639 https://askubuntu.com/a/293029/25639 – I do wish the installer could do that instead of asking dual-booters to compromise.

ronjouch 8y ago

Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base_system_changes_since_16.04_LTS https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base... > "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."

shittyadmin 8y ago
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
StavrosK 8y ago
Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.
- Jedd 8y ago
  > Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience. a) This hasn't ceased to work for your desktop - you can continue to do this through the upgrade cycle, as it would only affect new installs (safely converting native fs to dmcrypt isn't possible, AFAIK) b) during an installation you could eschew FDE and opt for a PV, as I do, that you put your selected, secure LV's onto. I use Debian in preference to Ubuntu, but I'm sure they're materially identical in this case -- two physical partitions -- /boot and not-boot. /boot isn't encrypted in my case, but /, and /home (and a couple of others, though not swap of course) are LVM2 volumes sitting on top of the encrypted 'rest of the disk' partition. If you have /home only with noauto option in fstab , pointing to a an LV on the crypted partition, you could continue to do what you're doing, with the same reduced security confidence.
- Rondom 8y ago
  Debian and Ubuntu allow running Dropbear in initramfs to prompt for the FDE password
  - StavrosK 8y ago
    That's fantastic to know, thank you. Do you know if it's complicated to set up?

unhammer 8y ago

Though unfortunately if you want to dual-boot, you have to manually set up the encryption :/ As in https://askubuntu.com/a/293029/25639 https://askubuntu.com/a/293029/25639 – I do wish the installer could do that instead of asking dual-booters to compromise.