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

[Paddy Landau]

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

**EDIT**
Refer to comment #47 for an alternative version.

[Oliver Grawert (ogra)]

full disk encryption is in the installer since several years (i think since 2012 but i might mis-remember) already ... see some howto site like: https://linoxide.com/ubuntu-how-to/two-methods-to-protect-your-data-using-ubuntu-disk-encryption/

[Paddy Landau (paddy-landau)]

Thank you, Oliver. That link was in fact one of the (many) reference pages used in creating the instructions. Unfortunately, it isn't actually full system encryption: /boot isn't encrypted, which allows for a clear attack vector.

[Oliver Grawert (ogra)]

then you shoud probably adjust the bug title to something like "full disk encryption should also encrypt /boot" and mark it as "whishlist"

[Paddy Landau (paddy-landau)]

Oliver, I've amended the title (the body of the report already says so). I don't know how to change it to "wishlist", although really, as I say, in today's world, it is nearly approaching a legal requirement (at least in the EU because of GDPR) than merely a wish.

[Paddy Landau (paddy-landau)]

Oliver, another point that I missed in my previous comments is that the full-disk encryption that Ubuntu uses does not play nicely with other systems. E.g., if you have Windows (true of most users), it will delete the entire Windows system plus its data.

The instructions given in the above report play nicely, and leave the other existing systems alone. I've amended the title to reflect this need.

[Phillip Susi (psusi)]

What do you mean by "attack vector"? /boot does not contain any sensitive files that you would want to protect from an attacker.

[Paddy Landau (paddy-landau)]

Phillip, do you feel that malware cannot be loaded onto /boot? If you are right, that would take me by surprise!

[Phillip Susi (psusi)]

Encryption does not stop someone from writing to the disk and putting different software on it. It just stops them from being able to read your data.

[Paddy Landau (paddy-landau)]

Phillip, you are correct only if the software partitions are unencrypted (as is the case with the existing default method). This bug report is about fully encrypting the entire system — that's everything, including swap and both root and /boot.

[Phillip Susi (psusi)]

That does not stop someone plugging in a usb stick and booting the machine with malware there.

[Paddy Landau (paddy-landau)]

Yes, I know this, Philip, but unlike with the current setup (where you can add malware to root and the kernel), with this method, the only thing that they can change is the ESP (EFI System Partition), because everything else is fully encrypted in a single partition using LVM within LUKS.

They can't add, modify or delete anything whatsoever anywhere else.

Not root.
Not the kernel.
Not /boot.
Not /home.
Nothing.

There's no access even to the file system.
You can't even see what type of file system it is, e.g. ext4 or BTRFS.
There's no access even to the partitioning.

All you can see when you boot with your malware USB is two physical partitions:

1. The ESP.

2. A single partition filled with apparently random data with a LUKS header. Not even a file system. Not even the partitioning details.

That's it.

It's not like ecryptfs, where you can see (and modify) the files in root and /boot, and where you can see (and corrupt) the files in /home even though the file names and contents are encrypted.

With LUKS, you can't see anything. At all.

Literally everything is encrypted apart from the ESP.

Everything.

Seriously.

The only way to add malware is to somehow mess with the ESP. It's a pretty tall order. I suppose that it could be done, theoretically, but I've yet to see anything along these lines being done.

And, when booting from the hard drive (not the malware USB), once you are past the EFI stage, Grub (which is encrypted and therefore cannot be replaced with malware) takes over, thereafter moving into Linux, which is encrypted and therefore cannot be replaced with malware.

I hope that you understand what I'm saying.

As you can see, it is a robust system that puts both Windows and the existing Ubuntu method to shame. I can't comment on Mac, because I haven't worked with it in decades.

So, can you see that I don't understand what you are getting at? I'm trying to understand your objection, but I am lost. I just cannot see it.

[Phillip Susi (psusi)]

Who cares *where* the malware is? Encryption doesn't stop someone from compromising the machine. You can boot the machine from a USB stick, then boot the hard disk in a virtual machine, let it look like it is running normally for you to come put your password in to decrypt the disk, and the malware on the USB stick ( or in the ESP ) can then capture your password and steal your data.

[Paddy Landau (paddy-landau)]

Phillip, I think that you need to take this discussion to somewhere like Ubuntu Forums.

If we were to accept your argument, we would say that there is no point whatsoever in encrypting anything, and we should eliminate the current option to encrypt the home folder when installing Ubuntu.

This approach violates, among others, the EU's GDPR.

We do need to encrypt our computers, and encrypting absolutely everything to help prevent malware is the best possible way forward.

Full-system encryption is possible (there is already a how-to for this), and it should be implemented as there is very little to do to make it available in the default installer.

We shall have to beg to differ on this, as your argument is unsuitable given the current technical, social and especially legal environment.

[Phillip Susi (psusi)]

On 6/21/2018 11:57 AM, Paddy Landau wrote:
> If we were to accept your argument, we would say that there is no point
> whatsoever in encrypting anything, and we should eliminate the current
> option to encrypt the home folder when installing Ubuntu.

No; it is not that there is no point; it is that you misunderstand the
point. The point is to prevent people from getting your data if they
steal your computer, not to prevent them from modifying the computer.

> We shall have to beg to differ on this, as your argument is unsuitable
> given the current technical, social and especially legal environment.

The GDPR is about keeping private data private ( and giving users
control over their data ), not about preventing tampering with a
computer given physical access to it ( which is impossible ).

[Paddy Landau (paddy-landau)]

> The point is to prevent people from getting your data if they steal your computer, not to prevent them from modifying the computer.

Sorry, no, that's not why I raised this bug report, Phillip. There definitely *is* a point in preventing someone from sneaking into your office (say, over the weekend), and loading malware in order to either modify or steal your data. This type of espionage does actually happen.

Full disk encryption prevents this, because I really don't think that you can load a virtual machine into the (at most) 400Kb of free space in the ESP and somehow transfer control to the ESP after you've done that. The alternative, leaving a USB stick in the machine and hoping that you won't notice a strange stick in your machine, is far too obvious to be effective.

Please, if you wish to continue this conversation further, please start something on the Ubuntu Forums and post the link here. I'll be happy to discuss it at length there, because this is taking it way off track on this bug report. The bug report is about converting the current halfway encryption method to a full encryption method, for all the right reasons. Just because someone "might" be able to load a virtual machine into the 400Kb of free ESP is hardly a reason to stick with the halfway method where someone definitely can load malware into the system.

Thank you

[Phillip Susi (psusi)]

On 6/22/2018 9:35 AM, Paddy Landau wrote:
> Sorry, no, that's not why I raised this bug report, Phillip. There
> definitely *is* a point in preventing someone from sneaking into your
> office (say, over the weekend), and loading malware in order to either
> modify or steal your data. This type of espionage does actually happen.
>
> Full disk encryption prevents this, because I really don't think that
> you can load a virtual machine into the (at most) 400Kb of free space in

No; it doesn't. At best it makes it slightly more difficult. Also the
ESP typically has a hundred mb of free space, not 400k.

> the ESP and somehow transfer control to the ESP after you've done that.
> The alternative, leaving a USB stick in the machine and hoping that you
> won't notice a strange stick in your machine, is far too obvious to be
> effective.

A usb stick plugged into the back of the computer isn't likely to be
noticed. You can also open up the case and put something inside. Or
for that matter, the stick only needs to be there to boot the computer
once, then it can be removed and the computer even made to go to sleep
and present fake boot screens if desired so that it looks like it is
booting normally when the user returns and turns it on. Or you can very
likely find a chunk of disk somewhere that you can compress to make room
to squeeze the malware onto the hard disk. Or a more sophisticated
attacker may plug in a PCIe card with malware on it, or compromise the
Intel management engine and have full remote control of your computer
over the network that is completely undetectable.

> Please, if you wish to continue this conversation further, please start
> something on the Ubuntu Forums and post the link here. I'll be happy to
> discuss it at length there, because this is taking it way off track on
> this bug report. The bug report is about converting the current halfway
> encryption method to a full encryption method, for all the right
> reasons. Just because someone "might" be able to load a virtual machine
> into the 400Kb of free ESP is hardly a reason to stick with the halfway
> method where someone definitely can load malware into the system.

If you think it's a good idea, then you should post about it to the
ubuntu-devel mailing list to discuss it.

[Paddy Landau (paddy-landau)]

Sorry, Phillip, yes, you're right about the ESP space ­— more like 100Mb. I was typing incorrectly; what I meant was at most 400Mb.

I'll look at the ubuntu-devel mailing list and post there. But that still doesn't obviate this request.

[Paddy Landau (paddy-landau)]

I have just discovered that home-folder encryption has been removed from Ubuntu because, it seems, it is considered buggy and under-maintained. Full-disk encryption is recommended as an alternative.

Reference:
https://www.linuxuprising.com/2018/04/how-to-encrypt-home-folder-in-ubuntu.html

As you already know, full-disk encryption wipes any existing OS such as Windows. Therefore, this gives extra impetus to this bug report.

Phillip, I posted the message on the board as you requested, but as there has been no reply, I consider this request to be fully valid.

[Milan Niznansky (online-minosi-deactivatedaccount)]

@Phillip

I believe that in the heat of the argument the key point was lost.

In the enterprise world, the "desktop" method of "lets assume we can wipe all user data" and "lets assume this is a single-disk use case" simply do not add up.

For me, the current model is simply unusable for 2 fundamental reasons:
A) As a corporate policy /precedes GDPR, but I presume it is not unique/ the only partition except from mandatory encryption is the EFI partition. This is not up for discussion. There is NO WAY you will even be able to win this argument with the InfoSec Crowd. Because they are right. You need to assume *not only* scenarios of external attacker but also the user himself mis-using the /boot partition to exchange confidential data. And please do not go with the "then you are already compromised so you lost anyway" argument. The point is is defense-in-depth. With trusted boot you can actually ignore the EFI-the system will refuse to boot if the EFI is messed with. Etc.

B) And this is even more critical, I have a powerfull workstation with several SSDs used as Virtualization host for a bunch of VMs under VMware workstation. I NEED to use custom partitioning to be able to create a custom LUKS volume and pass that volume directly to VMs to do their stuff - while staying fully encrypted on the HW level.

In summary, for "Kid's computer", the current approach is fine. No question there. Bu then, for a Kid's computer, Win10 is fine too so is a Mac ...

What this bug report is about is how to address PROFESSIONAL / ADVANCED use cases seemlessly.
Right now, the solution prepared by Paddy is absolutely fine - and it is even fine if it is NOT included in Uniquity.
But we should get the Grub bug fixed - bar the need for the "RefreshGrub" script, I found Paddy's solution infitintely more practical than being forced to use Red Hat (which supports a custom configuration just fine) or a Mac for that matter.

I am marking this against Grub too - as maybe first step is to fix the Grub bug and once that is done, consider extenting this to Ubiquity for the next LTS cycle.

[Dimitri John Ledkov (xnox)]

If you want to preserve other OS and setup encrypted partitions by hand, you can do so, since forever using the mini.iso d-i installer, and install ubuntu-desktop task.

yes unencrypted /boot is currently a limitation with grub, but you can use sicherboot package to boot UEFI based systems securely without /boot, as that ensure the bootloader, kernel, initramfs are all in the UEFI partition, signed and booted with secureboot.

none of that is typical for a desktop installer, nor is easy to explain in the UI. And things like above is adequatly easy to setup using the mini.iso and additional packages. For a mass-install corporate environment, I would expect internal sysadmins to either prepare d-i preseeds or custom golden images to deploy machines with such a sophisticated setup.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steve Langasek (vorlon)]

The source package for the current version of GRUB used in Ubuntu is grub2; reassigning.

[Paddy Landau (paddy-landau)]

@Dimitri Thanks for your comments. I understand where you are coming from.

I do think, however, that as Ubuntu is intended (and was intended right from day 1) to be "for human beings", it would make hugely more sense to support full-system encryption from the installer. People don't want to be messing around with "install this, then install that, then fix this other thing" especially as it's neither documented nor supported by Canonical.

That's just life.

While technical people love messing around — it's their job, after all! — your average "human being" hates it. (I also dislike it; I put together the method simply because I needed it. I documented the process publicly because I know that there are many, many people like me who need it.)

Also, I have never had good results from installing a desktop environment over an existing system, even something as simple as Lubuntu desktop over an Ubuntu installation.

That, too, is just life.

This request is something that Ubuntu should support. It's not a "nice to have" feature. In today's world, it's a a "got to have" feature, whether for business, government, professionals, salespeople, scientific research, and even personal use. (If I could program, I'd amend the installer myself to implement this — it is open source, after all).

This is made even more urgent by the fact that Ubuntu 18.04 no longer supports encryption at all. Even the recommended workaround, fscrypt, is broken.

I cannot understand the antagonism to this request — it's a proven method; it's not particularly difficult; it's easy enough to modify the existing installer to do this; it's significantly better than the existing options; it uses only proven technology; and it would prove hugely popular, helping to tip the balance to switch to Ubuntu in organisations that are currently uncertain.

I know that I were an internal sysadmin, or a consultant to a professional (I used to be both, decades ago), up to version 16.04 I would have recommended Ubuntu every time without hesitation. But, from 18.04, I absolutely would not, because it's too problematic to install with encryption and then keep it reliably up to date.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jonathan Polom (s0nic0nslaught)]

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 en...

[Jonathan Polom (s0nic0nslaught)]

I meant to add this in my preceding comment.

This is an example implementation of signed kernel and initramfs for Ubuntu: https://github.com/Phant0mas/ubuntu-secure-boot

Unsure if it works with 18.04, but this method could be implemented natively.

[Paddy Landau (paddy-landau)]

@Jonathan Polom (s0nic0nslaught)

Thank you for the extra information.

The full-system encryption linked in the OP solves the part about /boot being accessed, which is a good thing.

That leaves only three parts to be solved.

1. The error with Grub, which has been reported:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1062623

2. As you rightly say, the need to properly sign the Ubuntu kernel and initrd files. I think that this should be raised as a bug report if Ubuntu is to be taken seriously in corporate, government and other fields. So, on that note, how specifically should this bug be raised? I'll be happy to raise it if I know the specifics of what needs to be reported. Alternatively, if you know the details, perhaps you could please raise it and post the link here?

3. Implementing this process in the standard Ubuntu installer, which is what this bug request is about.

[Phillip Susi (psusi)]

What you are talking about is signature verification. You need the firmware to verify the signature on the kernel and initrd, using a custom self signing key only. That is unrelated to whether /boot is encrypted or not.

[Paddy Landau (paddy-landau)]

@psusi Yes, that's correct, and should be done in addition to this request. In other words, both are necessary.

[Phillip Susi (psusi)]

If your goal is secure boot, then you need signature verification. Encryption is not required for that. Encryption is for data privacy, and as I said before, nothing you consider private should be in /boot.

[Paddy Landau (paddy-landau)]

Phillip, the goal is BOTH secure boot AND encryption. This bug report specifically deals with the latter, not the former. Why are you so against encryption? I don't understand!

In the EU, GDPR is law, and in the rest of the world, encryption is pretty much already de rigueur.

If you are arguing that /boot shouldn't be encrypted, this is a direct contradiction of what you wrote earlier that malware can be loaded into the ESP; so why couldn't malware be loaded into /boot?

Please would you explain why you think that we should NOT encrypt /boot? The rest of us here are mystified; we should encrypt as much as possible in order to increase the barriers to black hats.

[Javier Paniagua Laconich (jpaniagualaconich)]

> Encryption is for data privacy and as I said before, nothing you consider private should be in /boot.
Well, not entirely correct. Encryption is also for tamper resistance, so it is still very useful even if nothing in /boot is private.

[Phillip Susi (psusi)]

On 9/7/2018 3:06 AM, Paddy Landau wrote:
> If you are arguing that /boot shouldn't be encrypted, this is a direct
> contradiction of what you wrote earlier that malware can be loaded into
> the ESP; so why couldn't malware be loaded into /boot?

It can. Encrypting it does not stop that.

> Please would you explain why you think that we should NOT encrypt /boot?
> The rest of us here are mystified; we should encrypt as much as possible
> in order to increase the barriers to black hats.

Because encryption does not prevent tampering. It protects private
data. With no private data in /boot, there is no need to protect it.

On 9/9/2018 5:40 PM, Javier Paniagua Laconich wrote:
> Well, not entirely correct. Encryption is also for tamper resistance, so it is still very useful even if nothing in /boot is private.

No, it isn't.

This belief that encryption prevents tampering strikes me as similar to
people thinking that RAID is a substitute for backups.

[Steffen Seeber (eremit7981)]

I would like to support this bug report from the perspective of a security oriented, pragmatic user, likely the kind of which there are plenty out there.

Ubuntu's great success has been and will be based on how user friendly it is, and an overwhelming majority of the people who are looking at security just want their whole system encrypted. Also in dual boot scenarios. Windows for general purpose, Ubuntu for security relevant tasks such as banking or sensitive administration. A wide-spread usecase.

Confronting them with exceptions such as an unencrypted /boot partition, disabling encryption in dual boot scenarios or any other unnecessary complications will just lower Ubuntu's acceptance in an increasingly security aware user world.

Academic discussions about whether or not encryption has been designed for tamper resistance just misses the point. Fact is that it does increase it. Think of someone who breaches my Windows installation, and discovers the parallel Ubuntu installation. They either just see one big chunk of random data, or they see a clear-text /boot partition they can play with. This is one unnecessary attack vector, no matter how easy or hard it is to use.

I do not remember a single argument in this whole history against /boot encryption that mentions a real disadvantage of the functionality. Yes, there may be alternatives. No, it does not make a system perfectly safe. But it helps, and not implementing it is like not implementing RAID because one wants to force users to create backups.

[Xavier Gnata (xavier-gnata-gmail)]

Any change to be able to install an encrypted Ubuntu 19.10 alongside of a win10?
I don't know if /boot should be encrypted but not being able to encrypt anything out of the box in 19.04 is a security regression. Crypaetup may not be perfect but it used to be good enough in many usecases.

[Paddy Landau (paddy-landau)]

Definitely, /boot should be encrypted. It has been proven possible, so there's every reason to do so.

[Xavier Gnata (xavier-gnata-gmail)]

Agreed.
"Full-system encryption needs to be supported out-of-the-box" full system shall mean 'the Linux partitions' an not 'the full disk'.
In 19.04 it is not possible to install an encrypted kubuntu in dual boot with windows10 without playing with the command line.

It means that no users new to Linux can encrypt the its Ubuntu. This is a severe security issue

[Xavier Gnata (xavier-gnata-gmail)]

The issue remains the same with 19.10 (beta I tried yesterday).
The 19.10 Kubuntu installer cannot install an encrypted kubuntu in dual boot with e.g. windows10.

It is still possible to setup such an encrypted kubuntu but it requires to chroot after the installer has finished its job and to configure crypttab manually. It is far from being user friendly and it gives a bad first impression.

[ersatz logins (ersatz-logins)]

+1 on this issue. Win 10 is required in my work environment, but not for *everything*; I can use Ubuntu for most of my work, but whole disk encryption *is* an absolute requirement. I've primarily used Ubuntu for more than a decade, and would much prefer to keep using it as my daily OS, but this is a blocker for me.

[Colin Pickup (colin-pickup)]

+1 to this issue. My new work laptop only has one drive. We require Windows for some tasks but Linux for others. Full drive encryption is mandatory for laptops and other portable devices.

[Dáire Fagan (dairefagan)]

+1. Fortunately I rarely have to use Windows, but I still do have to use it sometimes for work and study, and as such must maintain a dual boot on all of my systems. Please implement the fix.

[Xavier Gnata (xavier-gnata-gmail)]

Any chance to see a fix in 20.04?
We need to be able to encrypt (k)ubuntu data when ubuntu is installed alongside windows.
/home encrytion was not perfect but it was better than nothing.

[Valentyn Kovalenko (valik-dev)]

+1 to have a full disk encryption (boot+root+swap+home) in the next Ubuntu release out of the box.

[Jernej Jakob (jjakob)]

My attempts to install 20.04 beta desktop or 18.04 LTS netinstall expert mode with full disk LUKS encryption failed.

1. Tried installing 20.04 Desktop ISO:
- selected manual partitioning
- created a single partition spanning the entire disk
- created a volume for encryption on the partition (LUKS)
- the LUKS was created, but there is no way to select the sda1_crypt volume as physical device for LVM. The option is absent from the list! So I go manually:
- exit out of the installation
- open a terminal, create the LVM VG and two LVs: root and swap
- start the installer again, now the LVM volumes are displayed
- select the root volume to be used as ext4 on /
- select swap LV to be used as swap
- proceed with installation normally, it finishes without errors.
- on reboot, grub drops to rescue shell, unable to find the "lvm" root disk. Probably due to missing GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub.

2. Tried the 18.04 LTS netinstall booted over PXE:
- selected Advanced options, Expert Install
- used manual partitioning to create the same "MBR->partition1->LUKS->LVM->LVs root and swap" layout as above.
- installation proceeds fine until the "Install GRUB bootloader to the master boot record", where it errors: "grub-install /dev/sda failed". I try different combinations of grub options here, none work. So I'm unable to create a bootable system.

I could probably make the 2nd way work if I switched to the console, found out why it errors, fixed it, and installed it manually. But that's not expected of a normal user!

So now, in 2020, we have no way to install Ubuntu without unencrypted /boot. I have numerous machines that I either installed this way in the past, or manually copied over installations to hand-created LUKS and LVM, and with minor tweaks (chrooting into the copied system, adding GRUB_ENABLE_CRYPTODISK=y and tweaking fstab and crypttab) I can get them to boot fine.

I can swear this used to work on 14.04 and before, so this is a regression!

[Jernej Jakob (jjakob)]

By the way, PureOS has the same bug, so I think it goes all the way up to Debian.
Here's a guide I created on how to move a unencrypted install to fully encrypted (works with Ubuntu as well):

https://github.com/jjakob/wiki/wiki/Migrating-an-unencrypted-PureOS-Debian-install-to-fully-encrypted

[Paddy Landau (paddy-landau)]

@jjakob — Jernej, thank you for this useful and important information. I have included your link in the instructions:
https://help.ubuntu.com/community/ManualFullSystemEncryption
https://ubuntuforums.org/showthread.php?t=2399092

[Tom Reynolds (tomreyn)]

TJ wrote this:
https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019

[Paddy Landau (paddy-landau)]

@tomreyn — Tom, thank you for posting this. I have added it to these three documents:
https://help.ubuntu.com/community/ManualFullSystemEncryption
https://ubuntuforums.org/showthread.php?t=2399092
https://help.ubuntu.com/community/FullDiskEncryptionHowto

[Jernej Jakob (jjakob)]

TJ's howto from comment #47 is much better as it allows installing directly to the target disk, mine needs you to install it to a second disk and copies over to the target disk.

[kwz34 (m8dqq0zr)]

Any updates on this? This is really critical in my opinion. My user case:

- I work in a large, 1st rank university.

- Unfortunately, moronic administration decides that the default system is mac, or if specific programs needed Windows, for laptops (we have RedHat desktop PCs though).

- However, our IT has a tradition of allowing people to drift their own laptops, and they used to say yes to letting us be roots and buying what we wanted to dual boot Windows / Ubuntu. We do need windows in my group, so the only option is dual boot Windows / Ubuntu.

- Since the option to have encrypted Ubuntu at installation side by side with Windows in just one click has disappeared, we have had an epidemic of people techies enough to use Ubuntu, but not techies enough to understand / care about encryption etc, installing non-encrypted Ubuntu on the side of windows. IT has learnt about it, and was furious (this is a violation of the IT agreement we sign together with our work contract since it is a clear security breach), and has now forbidden people to install ubuntu / drift university laptops on their own.

- This means that we more or less cannot use Ubuntu any more until the one click encryption side-by-side with windows is back, and IT gets cool again. Really annoying. People either need to buy a separate laptop, and / or stop having ubuntu and move to mac.

[Xavier Gnata (xavier-gnata-gmail)]

Sad story.
This bug should be critical as it has large security impact. Encryption should be the norm.
It shall be possible to install an encrypted (k)ubuntu without being techy.

[Nodøn (nod0n)]

Encryption should also be possible without LVM. LVM is very good, but if you are using for example BTRFS, you may don't want to use both at the same time. Should just be an option.

[Xavier Gnata (xavier-gnata-gmail)]

Well it's an issue indeed but the fact that no encryption is possible
without having to deal with the command line is much worst.

Le lun. 21 déc. 2020 à 22:15, Nodøn <email address hidden> a écrit :

> Encryption should also be possible without LVM. LVM is very good, but if
> you are using for example BTRFS, you may don't want to use both at the
> same time. Should just be an option.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Confirmed
>
> 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
>
> **EDIT**
> Refer to comment #47 for an alternative version.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1773457/+subscriptions
>

[Paddy Landau (paddy-landau)]

This doesn't look like it'll ever be done. Based on past experience, I don't think that Canonical takes encryption seriously.

So, I've thrown in the towel. Since buying a new computer, I haven't used dual-boot. Instead, I installed Ubuntu using its full-disk LUKS encryption. I run Windows in a VM (VirtualBox) inside Ubuntu, so that LUKS also protects it.

It's a good solution provided that your hardware is powerful enough. If your hardware isn't up to it, you don't have much choice.

[Xavier Gnata (xavier-gnata-gmail)]

No it is not a grub issue. It's an issue with the installer which does not
provide this option anymore. Wishlist..kind of but I think it is much
closer to a big security issue than to a wishlist. The net result is that
people do install kubuntu without any encryption.

Le mar. 22 déc. 2020 à 19:40, Julian Andres Klode <
<email address hidden>> a écrit :

> ** Changed in: grub2 (Ubuntu)
> Importance: Undecided => Wishlist
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Confirmed
>
> 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
>
> **EDIT**
> Refer to comment #47 for an alternative version.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1773457/+subscriptions
>

[Julian Andres Klode (juliank)]

The issue reported here is that /boot is not encrypted in the supported configurations. Which is meh - we don't have much authenticated encryption, so boot can still be manipulated. Sealed TPM measurements address the problem of verifying the bootloader, kernel, initrd, and the configuration better. It does not provide security by obfuscation as encryption does, but that obfuscation can be circumvented - you can modify an encrypted boot partition and still get a working system - and authenticated encryption that would also authenticate the content is not stable yet.

I cannot say much on the other issue raised in recent comments on dual boot setups not installing encrypted, but I fail to see how it's related to this bug report

I do want to point out that with devices now being sold with BitLocker out of the box, that you do have to disable BitLocker first to even get the ability to install another OS, so I fail to see how that improves the situation for dual boot users who need encryption.

But in any case adding comments to bugs that are unrelated to the bug is not really helpful, you end up with nobody knowing what people are talking about anymore.

Hence my suggestion would be to open a new bug report against ubiquity describing the dual boot setup issues so that that can be tracked on its own and we don't have to discuss two bugs in one bug report.

[Xavier Gnata (xavier-gnata-gmail)]

Right.
https://bugs.launchpad.net/bugs/1799550 has been opened in 2018 to track
the dual boot issue. This is the security issue I was referring to. Sorry
for the confusion.

Le mar. 22 déc. 2020 à 22:30, Julian Andres Klode <
<email address hidden>> a écrit :

> The issue reported here is that /boot is not encrypted in the supported
> configurations. Which is meh - we don't have much authenticated
> encryption, so boot can still be manipulated. Sealed TPM measurements
> address the problem of verifying the bootloader, kernel, initrd, and the
> configuration better. It does not provide security by obfuscation as
> encryption does, but that obfuscation can be circumvented - you can
> modify an encrypted boot partition and still get a working system - and
> authenticated encryption that would also authenticate the content is not
> stable yet.
>
> I cannot say much on the other issue raised in recent comments on dual
> boot setups not installing encrypted, but I fail to see how it's related
> to this bug report
>
> I do want to point out that with devices now being sold with BitLocker
> out of the box, that you do have to disable BitLocker first to even get
> the ability to install another OS, so I fail to see how that improves
> the situation for dual boot users who need encryption.
>
> But in any case adding comments to bugs that are unrelated to the bug is
> not really helpful, you end up with nobody knowing what people are
> talking about anymore.
>
> Hence my suggestion would be to open a new bug report against ubiquity
> describing the dual boot setup issues so that that can be tracked on its
> own and we don't have to discuss two bugs in one bug report.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Confirmed
>
> 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 li...

[pataquets (pataquets)]

This helped me with Win10/Ubuntu22.04 Dual-boot install with a Windows encrypted (BitLocker) partition. Worked great and I've achieved encryption on both OSes:
https://www.mikekasberg.com/blog/2020/04/08/dual-boot-ubuntu-and-windows-with-encryption.html

[Xavier Gnata (xavier-gnata-gmail)]

Yeah but it should b possible out of the box. That's a matter of security.

Le mar. 10 janv. 2023 à 22:44, pataquets <email address hidden> a
écrit :

> This helped me with Win10/Ubuntu22.04 Dual-boot install with a Windows
> encrypted (BitLocker) partition. Worked great and I've achieved encryption
> on both OSes:
>
> https://www.mikekasberg.com/blog/2020/04/08/dual-boot-ubuntu-and-windows-with-encryption.html
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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:
> Confirmed
>
> 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
>
> **EDIT**
> Refer to comment #47 for an alternative version.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1773457/+subscriptions
>
>