Comment 11 for bug 1773457

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.