Comment 25 for bug 1773457

I am with Paddy on this one. This isn't a "nice to have" feature but an essential feature that any operating system with even a sliver of hope of enterprise-wide adoption needs to support in the second decade of the 21st century. Windows has the benefit of fully supporting TPM based encryption and secure boot which so each item loaded at boot time has a cryptographic signature which is verified by the secure boot system. Modifications will result in an un-bootable system. Mac OS X has FileVault along with System Integrity Protection which similarly will make it very difficult to boot poisoned pieces of the operating system to extract bits of information that should be protected on disk by encryption. Ubuntu, at this point, does not offer a level of tamper-resistance similar to this without implementing unsupported modifications that (like this method) are not for ordinary users who just want to install something "that works." This is both deeply disappointing to a security and privacy minded individual like myself and it WILL prevent adoption of this system in areas where complete system encryption and built-in tamper resistance are non-negotiable requirements (defense, financial, legal, healthcare, and more -- most industries are very security conscious now).

I'm blown away by the animosity shown by some that have commented on this thread who dismiss this issue has unnecessary because "encryption isn't supposed to be used to prevent modification of items on disk" or that "the bug isn't really against the named packages" or to "use the minimal installer" to do this. A leading operating system (which Ubuntu should be considered one at this point) in the 21st century needs to support an easy, out of the box way to ensure private information stays private.

The proof of concept attack to which the "full disk" encryption method supported by the Ubiquity installer is vulnerable to is fairly straight-forward to implement. It does require physical access to a system but this requirement is generally met when the device is portable, aka a laptop. Please see the procedure described here to understand how initrd/initramfs poisoning works: https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/

Considering the relatively simplicity of this attack, as well as the existence of a clear way to remove this vulnerability, I think this issue needs to be addressed both in terms of updating the full disk encryption method supported in the installer, along with fixing the grub2 package so the issue Paddy had to write a script to fix no longer exists.

I'd also like to offer an alternative method which could/should be examined for more official support, and that is to truly support secure boot by using signed kernel and initrd images. This would require Ubuntu to build in a way to sign kernels and initrd files with the Microsoft key, or to create self-signed keys on each machine and install them into the EFI. I almost prefer this version because it it uses secure boot for what it is intended to do: ensure the files loaded at boot time have not been tampered with.

Finally, I'd like to add that Ubiquity also needs to support doing encryption with a btrfs root, which currently will result in a non-bootable system if you manage to configure it as such. When using btrfs as root it would also be nice if it supported an encrypted root without the use of LVM since btrfs over LVM is kind of redundant.