So, one of your arguments from this post is that there is no way to enforce the kernel cmdline if booted as an EFI executable, but I am doing exactly that since quite some time: I roll the kernel, initrd and cmdline into one EFI binary and then sign that. AFAIK this prevents anyone from changing the cmdline (please correct me if I am wrong). I think I even learned about this possibility from this very blog :)
However, I think I realize why this "doesn't count" for your argumentation: It would be highly impractical for a distribution to ship this signed blob, as the initrd is usually generated on the users system and the cmdline might also need to account for the users individual setup (root partition or mount arguments at least). So from a Distributions perspective I want lockdown linked to UEFI because then I can sign this lockdown-enabled kernel, ship it, and guarantee to every user that - if secure boot is on and my keys are enrolled in the firmware - whatever kernel or OS may have been booted or chainloded into, it was signed by me and hadn't be tampered with.
I already see a problem with this: How can the user check if secure boot is actually enabled? If someone managed to compromise the system and turn secure boot off (for example by using shim), they could just boot a system that makes it look like secure boot is enabled. But this is not my main problem with the patch:
Currently, I am using my distributions prebuilt kernel, as I've had no need for custom kernel options since a long time. I also use secure boot to verify my kernel+initrd+cmdline, as mentioned earlier. I don't really trust the proprietary implementation of it, but it's better than not using secure boot. Everything besides the UEFI boot partition is encrypted, so I "use" this encryption to further verify my boot chain. I know that it's theoretically possible to tamper with an encrypted disk without knowing the encryption key, but again better than nothing. So I really don't want to disable secure boot, but I might want to disable lockdown (and I can imagine that there are more people who want that than just me). Maybe I want to chainload into something unsigned, but I (sufficiently) trust it because it comes from my encrypted disks. But if my distribution enables the lockdown option as is, I would have to build my own kernel from now on, until possibly forever. I might even have to maintain my own patch set if I want to leave lockdown available as a cmdline option, but not tie it to secure boot! That, or the distribution still would have to ship two kernels: One with lockdown tied to secure boot, signed; one with lockdown not tied to secure boot, unsigned.
So, this might actually be a user vs distribution thing. The user wants to disable lockdown without disabling secure boot, but the distribution wants to be able to give guarantees to other users (or maybe other software vendors).
As a user, I don't want to accept the lockdown patches as is. But I think there is another way to solve this, which might be acceptable to Distributions: The distribution ships a tiny signed bootloader that enforces the lockdown argument on the cmdline. The kernel is then signed in a different way, so it can't be booted directly with secure boot but only via the bootloader. There is still an amount of work needed for this (mainly signing the kernel in this "different way"), but it probably beats shipping two kernels, one with a possibly out-of-tree version of lockdown. And I would definitely prefer this over rolling my own kernel from now ;)
Another tiny thing: If the current lockdown patches allow for lockdown to be disabled with alt-sysrq-x during runtime, wouldn't this invalidate all the efforts of lockdown? Say I boot a signed Fedora, disable lockdown, then somehow chainload into a modified Windows which sees secure boot is still active?
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
User vs Distribution
Date: 2018-04-08 01:23 am (UTC)AFAIK this prevents anyone from changing the cmdline (please correct me if I am wrong). I think I even learned about this possibility from this very blog :)
However, I think I realize why this "doesn't count" for your argumentation: It would be highly impractical for a distribution to ship this signed blob, as the initrd is usually generated on the users system and the cmdline might also need to account for the users individual setup (root partition or mount arguments at least).
So from a Distributions perspective I want lockdown linked to UEFI because then I can sign this lockdown-enabled kernel, ship it, and guarantee to every user that - if secure boot is on and my keys are enrolled in the firmware - whatever kernel or OS may have been booted or chainloded into, it was signed by me and hadn't be tampered with.
I already see a problem with this: How can the user check if secure boot is actually enabled? If someone managed to compromise the system and turn secure boot off (for example by using shim), they could just boot a system that makes it look like secure boot is enabled.
But this is not my main problem with the patch:
Currently, I am using my distributions prebuilt kernel, as I've had no need for custom kernel options since a long time. I also use secure boot to verify my kernel+initrd+cmdline, as mentioned earlier. I don't really trust the proprietary implementation of it, but it's better than not using secure boot. Everything besides the UEFI boot partition is encrypted, so I "use" this encryption to further verify my boot chain. I know that it's theoretically possible to tamper with an encrypted disk without knowing the encryption key, but again better than nothing.
So I really don't want to disable secure boot, but I might want to disable lockdown (and I can imagine that there are more people who want that than just me). Maybe I want to chainload into something unsigned, but I (sufficiently) trust it because it comes from my encrypted disks.
But if my distribution enables the lockdown option as is, I would have to build my own kernel from now on, until possibly forever. I might even have to maintain my own patch set if I want to leave lockdown available as a cmdline option, but not tie it to secure boot!
That, or the distribution still would have to ship two kernels: One with lockdown tied to secure boot, signed; one with lockdown not tied to secure boot, unsigned.
So, this might actually be a user vs distribution thing. The user wants to disable lockdown without disabling secure boot, but the distribution wants to be able to give guarantees to other users (or maybe other software vendors).
As a user, I don't want to accept the lockdown patches as is. But I think there is another way to solve this, which might be acceptable to Distributions: The distribution ships a tiny signed bootloader that enforces the lockdown argument on the cmdline. The kernel is then signed in a different way, so it can't be booted directly with secure boot but only via the bootloader. There is still an amount of work needed for this (mainly signing the kernel in this "different way"), but it probably beats shipping two kernels, one with a possibly out-of-tree version of lockdown. And I would definitely prefer this over rolling my own kernel from now ;)
Another tiny thing: If the current lockdown patches allow for lockdown to be disabled with alt-sysrq-x during runtime, wouldn't this invalidate all the efforts of lockdown? Say I boot a signed Fedora, disable lockdown, then somehow chainload into a modified Windows which sees secure boot is still active?