| Lennart is technically doing good work.
While his tools are less complicated than the current hilariously convoluted standard boot process, they are still too complicated to use well. He also misses the point with the attack scenarios.
If you luks encrypt your data and choose a good passphrase, the brunt is done against theft.
Protecting against bad passwords is futile in the long run. (Will elaborate if requested.)
That someone images your drive for offline bruteforce or manipulates your boot binaries is rare.
The true benefit of signed boot chain is to have security patches work reteoactively, "compromise recovery".
Automated attacks and malware from the internet side are way more common. Imagine one of your daemons is compromised. As long as it does not escalate privileges, it can only gain persistence via corruptable data files or config accessible to itself.
Now a patch comes along that closes the hole that reinfects the daemon.
The malware will not start on daemon restart. With signed booting you can bring that to the kernel and root. Signed booting with rollback protection into a known good state.
As long as the malware is not part of that system it won't run on launch. But who signs my stuff, especially my own scripts and automation?
Me of course, if I had good tooling. If that became normal malware would just steal the key. A TPM or other keybearer device lets you conditionally unlock a signing key. So to sign, you can boot your system into a runlevel / target / ... that does not run auxiliary scripts from writable locations.
If that state is measured by the TPM, you can sign. With good enough tooling this is workable. If implemented well, this even helps maintenance of the system. In the state of things now, its a horrible convoluted mess that doesnt give extra security but 10 more points at which you can break your boot. + UEFI itself is again a complexity monster full of holes on very many machines.
The whole x86 preboot stack amd or intel is a horrible complexity monster. |
There's already a mechanism, provided for DKMS - you enrol a 'Machine Owner Key' which only root can access, and any time you update your kernel (requiring you to recompile a kernel module), it gets signed with the MOK. Which of course means any malware that gains root access can sign itself too.
An alternative is that any time you update your kernel and reboot, things like the nvidia drivers would get disabled until you perform some special ceremony. Not that great for usability, we want people to install updates in a timely manner after all so we don't want to make it too inconvenient.
Another alternative is to only load code blessed by a Microsoft-approved Linux distro - the Ubuntu Core approach. But this requires abandoning the open source ethos.