Securing the Linux boot process

Matthew Garrett

Linux has had support for UEFI Secure Boot for some time, which helps secure part of the boot process - you can be reasonably sure that nobody's replaced your bootloader or kernel, and that's sufficient to cover a bunch of cases. But for various technical reasons there's still a number of security critical components that are entirely unverified and which can be replaced by an attacker, and that means anyone with access to your system can configure it to steal (say) your hard drive encryption password. That's suboptimal.

There are various solutions to this involving TPMs, but so far they've all involved a lot of manual configuration and run the risk of being locked out of your machine for upgrading your kernel at the wrong time. Surely we can do better?

Unsurprisingly, yes. This presentation will describe some light modifications to the way distributions ship components that will make it possible to ensure that systems boot without running the risk of sensitive credentials being stolen but also without compromising the flexibility of the existing Linux boot process.

[pm]

It really seems there should be betters ways than multiple initrds and appending to kernel command line.
I bet that someone will find a configuration/cmdline thingy, which weren't considered security relevant, but which turns out to be an exploit vector.