Kernel lockdown in 4.17?

Posted Apr 5, 2018 11:21 UTC (Thu) by SLi (subscriber, #53131)
Parent article: Kernel lockdown in 4.17?

> In theory, the secure-boot chain of trust ensures that the system will never run untrusted code in kernel mode. On current Linux systems, though, the root user (or any other user with sufficient capabilities) can do exactly that. For anybody who wants to use secure boot to ensure the integrity of their systems (or, perhaps, to prevent their customers from truly owning the system), this hole defeats the purpose of the whole exercise.

Do I understand correctly that it not only defeats the purpose for Linux users, but actually for everybody anywhere ever using secure boot, if a signed kernel image allowing arbitrary kernel code to run exists? Couldn't such a kernel be used to boot another secure OS with a false assurance that the boot process has not been tampered with? Or is there some step where the signature of the booted kernel is measured by a TPM in a way that another secure boot targets in reality can detect (wouldn't that also prevent using Grub to boot them, since that's not distinguishable from the kernel in a meaningful way)?

to post comments

Kernel lockdown in 4.17?

Posted Apr 6, 2018 1:15 UTC (Fri) by neilbrown (subscriber, #359) [Link]

> Do I understand correctly that it not only defeats the purpose for Linux users, but actually for everybody anywhere ever using secure boot, if a signed kernel image allowing arbitrary kernel code to run exists?

Not really.
With physical access, you can install the keys of your choice into your hardware (if you cannot, then it isn't your hardware).
Each key should have some policy associated, with the meaning "This will only be used to sign code which abides by the given policy". If anything else ever gets signed, then the key is compromised.
If there is some particular policy that you want to impose, then you should disable any keys that have a broader policy, or that have been compromised.