Indeed: 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."
> "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."
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.
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.
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.
This would certainly be more work to set up than vanilla full-disk encryption, though.
"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.
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.
"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."
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.