[Bug 1773457] Re: Full-system encryption needs to be supported out-of-the-box including /boot and should not delete other installed systems

[Jonathan Polom]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1773457

Title:
  Full-system encryption needs to be supported out-of-the-box including
  /boot and should not delete other installed systems

Status in grub2 package in Ubuntu:
  Confirmed
Status in ubiquity package in Ubuntu:
  Incomplete

Bug description:
  In today's world, especially with the likes of the EU's GDPR and the
  many security fails, Ubuntu installer needs to support full-system
  encryption out of the box.

  This means encrypting not only /home but also both root and /boot. The
  only parts of the system that wouldn't be encrypted are the EFI
  partition and the initial Grub bootloader, for obvious reasons.

  It should also not delete other installed systems unless explicitly
  requested.

  On top of this, the previous method of encrypting data (ecryptfs) is
  now considered buggy, and full-disk encryption is recommended as an
  alternative. Unfortunately, the current implementation of full-disk
  encryption wipes any existing OS such as Windows, making the
  implementation unusable for most users.

  Now, using LUKS and LVM, it is already possible to have full-disk
  encryption (strictly, full-partition encryption because it leaves any
  existing OS alone), while encrypting /boot. Reference:

  https://help.ubuntu.com/community/ManualFullSystemEncryption

  ... but with one major limitation: Grub is incorrectly changed after
  an update affecting the kernel or Grub, so that a manual Grub update
  is required each time this happens (this is fully covered in the
  linked instructions).

  If the incorrect Grub change is fixed, it should be (relatively)
  simple to support full-system encryption in the installer.

  Further information (2018-08-17):

  The NCSC recommends, "Use LUKS/dm-crypt to provide full volume encryption."
  References:
  • https://blog.ubuntu.com/2018/07/30/national-cyber-security-centre-publish-ubuntu-18-04-lts-security-guide
  • https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1804-lts

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1773457/+subscriptions