On 6/27/22 13:34, Chris Murphy wrote:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features.
If users can load arbitrary unsigned kernel modules or hibernation images, it silently circumvents UEFI Secure Boot. I agree this is a frustrating paradigm for users who want certain features like using 3rd party modules with a Fedora kernel, or using locked down kernel features, but I'm not sure what the alternative is.
The alternative is to accept that UEFI Secure Boot only provides meaningful security if the default signing keys (in particular, Microsoft’s) are not installed. On Windows, administrator to kernel is not considered a security boundary, so there is no point pretending it is one on Linux if the attacker can just boot Windows. If you are interested in *actual* pre-boot security, I suggest Heads (https://osresearch.net) or at least enrolling your own certificates (which should be sealed to the TPM such that the private keys are only available after successful boot of a signed OS). The initramfs also needs to be signed, and the signature needs to be checked before it is run.