On 6/27/22 13:34, Chris Murphy wrote:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer
<fweimer(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)