Manual Full System Encryption has been updated and simplified

[elgo2]

Thank you Paddy! The troubleshooting guide worked perfectly! You are a lifesaver!

Yes, I am using Ubuntu 18.04. The issue arose when I tried to restore a backup done with Timeshift.

NB: As for newer versions of Ubuntu I did try your guide on 19.10 but it didn't work for me.

A question - isn't grub located on /boot and /boot is encrypted - so how does it work prior to me entering the password? Or is there another grub on /efi and that's the grub that I refreshed following your troubleshooting guide?

[Paddy Landau]

A question - isn't grub located on /boot and /boot is encrypted - so how does it work prior to me entering the password? Or is there another grub on /efi and that's the grub that I refreshed following your troubleshooting guide?

I don't know. I created this guide after frustration with the lack of progress from Canonical, by following the advice of several internet-based sources. I'm not really a technical person, so much of what I did was just trail and error, and I understand barely anything about how Grub works.

[elgo2]

I don't know. I created this guide after frustration with the lack of progress from Canonical, by following the advice of several internet-based sources. I'm not really a technical person, so much of what I did was just trail and error, and I understand barely anything about how Grub works.

Do you know if there is a way we can suggest (petition) this feature to Canonical?

Another question - I have /home on a separate partition from /boot and /root. In case I need reinstall Ubuntu (which will format the partition) is there a way to leave the /home partition untouched? I would think I would need to preserve the keyfile, but how would I tell your script not to format /home and use an existing keyfile?

[Paddy Landau]

Do you know if there is a way we can suggest (petition) this feature to Canonical?

The main document lists four bug reports under Important Notes > Bug requests. You can vote for the reports. For each report:

• Go to the bug report.
• Log in (top-right corner) if not already logged in.
• Press on the green writing that says, "This bug affects nn people. Does this bug affect you?", and select "Yes, it affects me".

Other than that, I'm unsure how else you can raise this to Canonical. If we can get many people to vote on the reports, it will raise their profile (the "bug heat", as shown by the little fire symbol on the right-hand side). I find it baffling that Canonical is trying to make money from selling their services for Ubuntu to businesses, but they treat fundamental security with an apathetic attitude.

I have /home on a separate partition from /boot and /root. In case I need reinstall Ubuntu (which will format the partition) is there a way to leave the /home partition untouched? I would think I would need to preserve the keyfile, but how would I tell your script not to format /home and use an existing keyfile?

It is possible. Warning: I haven't tested this, so please back up your home partition in case of problems! (You should be backing up your home partition anyway on a regular basis.)

EDIT: As reported by @elgo2, this won't work!

1. Boot from a Live CD.
2. Unlock your partitions as explained in Computer fails to boot after upgrade or new installation, steps 1–5 only.
3. Delete all files on your root with the following command.
   

   rm --one-file-system --recursive /mnt/root

4. Follow the Ubuntu installation instructions.
5. Continue with Fix broken pieces.
6. Complete Check and finalise.

I repeat that I haven't tested this, so I can't guarantee that it will work.

[elgo2]

The main document lists four bug reports under Important Notes > Bug requests. You can vote for the reports. For each report:

• Go to the bug report.
• Log in (top-right corner) if not already logged in.
• Press on the green writing that says, "This bug affects nn people. Does this bug affect you?", and select "Yes, it affects me".

Other than that, I'm unsure how else you can raise this to Canonical. If we can get many people to vote on the reports, it will raise their profile (the "bug heat", as shown by the little fire symbol on the right-hand side). I find it baffling that Canonical is trying to make money from selling their services for Ubuntu to businesses, but they treat fundamental security with an apathetic attitude.

Perhaps they provide a "secure" version to businesses?

I gave my vote on all 4 bugs.

But maybe we should start a petition to request a "true" Full Disk Encryption from Canonical. I believe it would have a higher impact since it would be easier for people to vote and more people would vote.

It is possible. Warning: I haven't tested this, so please back up your home partition in case of problems! (You should be backing up your home partition anyway on a regular basis.)

1. Boot from a Live CD.
2. Unlock your partitions as explained in Computer fails to boot after upgrade or new installation, steps 1–5 only.
3. Delete all files on your root with the following command.
   

   rm --one-file-system --recursive /mnt/root

4. Follow the Ubuntu installation instructions.
5. Continue with Fix broken pieces.
6. Complete Check and finalise.

I repeat that I haven't tested this, so I can't guarantee that it will work.

A couple of things that I'm missing...

1. How do I continue with Fix broken pieces? If I run your script it would start from the beginning - i.e. asking for passwords, partitions, etc.? Do I start it with some parameter that tells it to skip the initial part?

2. How would /home be auto-mounted? Wouldn't it need the current keyfile for that? So do I have to backup the current keyfile and then copy it to the newly installed Ubuntu on /root?

[Paddy Landau]

But maybe we should start a petition to request a "true" Full Disk Encryption from Canonical. I believe it would have a higher impact since it would be easier for people to vote and more people would vote.

Nice idea, but I wouldn't know how to do that. Also, as Canonical is a private company based in the UK, they can just ignore petitions, and it's not possible to put shareholder pressure on them.

If you have a good idea of how to get Canonical to take this issue seriously, I'd love to hear.

The only option that Canonical currently supports is full-disk encryption, which means erasing everything else on the hard drive, including Windows. It also means, as far as I understand, that reinstalling Ubuntu without wiping your home folder isn't possible. It also doesn't encrypt boot.

1. How do I continue with Fix broken pieces? If I run your script it would start from the beginning - i.e. asking for passwords, partitions, etc.? Do I start it with some parameter that tells it to skip the initial part?
2. How would /home be auto-mounted? Wouldn't it need the current keyfile for that? So do I have to backup the current keyfile and then copy it to the newly installed Ubuntu on /root?

Ah, yes, you're absolutely correct. I missed that. My bad, sorry.

I've been looking at the script. I tried to figure out a workaround for this, but it would be awfully complex. I think that you'd have to manually follow the process, which (as warned in the documentation) is only for advanced people; specifically, for people who thoroughly understand both LUKS and LVM.

If this is not you, your best way forward is to reinstall afresh, and then restore your home folder from your backups.

Sorry that I can't be of better help.

[elgo2]

I could create a petition that asks Canonical to create FDE that includes /boot and works with Secure Boot. That's a start and should be fairly easy for them to implement. Here's an example discussion. Any suggestions on the wording of the petition - i.e. is what I said technically correct and specific enough?

[Paddy Landau]

I could create a petition that asks Canonical to create FDE that includes /boot and works with Secure Boot. That's a start and should be fairly easy for them to implement. Here's an example discussion. Any suggestions on the wording of the petition - i.e. is what I said technically correct and specific enough?

For some reason, Ubuntu Forums frequently fails to notify me of new posts, so sorry that I'm responding only now.

I am feeling somewhat disillusioned, because every time that this issue is raised on the official channel, some person comes in and says that full-disk encryption is not worthwhile because there are some ways to hack a system. The argument makes no sense.

Here is a suggestion, but please feel free to amend as you see fit.
____________________________________

Title

Ubuntu needs full-system encryption plus Secure Boot that doesn't interfere with existing partitions (e.g. Windows)

Body

Today's malware, regulations including GDPR, and threat of lawsuits and fines require the best security available to business large and small, governments, NGOs and other organisations, and to individuals. As we have seen in the news more than once, losing an unencrypted laptop or having its operating system unencrypted (even when data is encrypted) can have severe consequences.

Ubuntu needs to step up to the challenge by encrypting not just the data partition but also the operating system. It should look at encrypting as much as is possible, including /boot. Secure Boot should be supported as an integral part of this.

The instructions at the following link offer proof-of-concept.
https://help.ubuntu.com/community/Ma...stemEncryption

The entire Ubuntu system, including swap (if used), root, /home and /boot, is held on a single LUKS-encrypted partition using LVM. (The system can be modified to allow multiple logical partitions and physical disks, whether or not joined with LVM.) It even permits hibernation. This creates a powerful level of encryption. Only the EFI System Partition (ESP) is left unencrypted for obvious reasons.

This system respects other already-existing systems such as Windows, and does not overwrite them.

This proof of concept shows that nothing prevents this from being done. By including this by default into the standard Ubuntu installation, Canonical will be able to boast one of the most secure implementations of an operating system, using Secure Boot and full encryption of everything.

Understandably, the ESP cannot be encrypted, but that is the whole point of using Secure Boot to mitigate that problem.

Some people have argued that because ESP is unencrypted, that means that there is no point in encrypting anything, but that is a spurious argument with no merit (otherwise no one would bother to encrypt anything) and an argument that regulators, among others, would dismiss out of hand.

[Dáire Fagan]

Paddy, I would love if I could use Gnome 3.2 with this setup, not least because alt+tab for me very often freezes my system, but I understand with 18.04 we are locked in to 3.28.2 with this setup.

There is a work around here: How to install gnome 3.29.92 or 3.30 in Ubuntu 18.04?

I am hesitant to implement that just yet in case it breaks something not easily reversible.

Have you any plans to update your script and guide so that it supports a more recent version of Ubuntu, and if you do, will you provide a script that allows those of us who have already followed it to setup 18.04 to upgrade?

[Paddy Landau]

Jernej Jakob has created instructions to convert an unencrypted installation to an encrypted one. I have not tested it, but Jernej says that it works on Ubuntu. I have amended the first post to include this information.