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

Bug #1773457 reported by Paddy Landau on 2018-05-25
214
This bug affects 47 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Undecided
Unassigned
ubiquity (Ubuntu)
Undecided
Unassigned

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

Oliver Grawert (ogra) wrote :

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) wrote :

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) wrote :

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

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.

summary: - Full-system encryption needs to be supported out-of-the-box
+ Full-system encryption needs to be supported out-of-the-box including
+ /boot
Paddy Landau (paddy-landau) wrote :

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.

summary: Full-system encryption needs to be supported out-of-the-box including
- /boot
+ /boot and should not delete other installed systems
description: updated
Phillip Susi (psusi) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Incomplete
Paddy Landau (paddy-landau) wrote :

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

Phillip Susi (psusi) wrote :

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) wrote :

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) wrote :

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

Paddy Landau (paddy-landau) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

> 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) wrote :

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) wrote :

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) wrote :

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.

description: updated

@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) wrote :

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) wrote :

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

Steve Langasek (vorlon) wrote :

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

affects: grub (Ubuntu) → grub2 (Ubuntu)
Changed in grub2 (Ubuntu):
status: New → Confirmed
Paddy Landau (paddy-landau) wrote :

@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) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
description: updated
Download full text (3.4 KiB)

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

Read more...

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) wrote :

@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) wrote :

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) wrote :

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

Phillip Susi (psusi) wrote :

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) wrote :

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.

> 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) wrote :

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.

spm2011 (spm2011) on 2018-09-11
tags: added: bionic cosmic
Steffen Seeber (eremit7981) wrote :

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.

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) wrote :

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

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers