On Thu, Apr 7, 2022 at 8:28 AM Lennart Poettering <mzerq...@0pointer.de> wrote:
>
> On Di, 05.04.22 17:38, Chris Murphy (li...@colorremedies.com) wrote:
>
> > When users have a suboptimal experience by default, it makes Fedora
> > look bad. We can't have security concerns overriding all other
> > concerns. But it's really pernicious to simultaneously say security is
> > important, but we're also not going to sign proprietary drivers. This
> > highly incentivizes the user to disable Secure Boot because that's so
> > much easier than users signing kernel modules and enrolling keys with
> > the firmware, and therefore makes the user *less safe*.
>
> Let me stress one thing though: Fedora *has* *no* working SecureBoot
> implementation. The initrd is not authenticated. It has no signatures,
> nothing.
>
> By disabling SecureBoot you effectively lose exactly nothing in terms
> of security right now.
>
> What good is a trusted boot loader or kernel if it then goes on
> loading an initrd that is not authenticated, super easy to modify (I
> mean, seriously, any idiot script kiddie can unpack a cpio, add some
> shell script and pack it up again, replacing the original one) – and
> it's the component that actually reads your FDE LUKS password.
>
> I mean, let's not pretend unsigned drivers were a big issue for
> security right now. They are now, we have much much much wider gaping
> holes in our stack.

I agree that the lack of a signed initrd is a big gaping hole. I don't
agree it's pointless to ensure the bootloader, kernel and kernel
modules are authentic. It's bad to have malware running in user space.
It's extra bad if it's running in kernel space. There are examples of
such malware, including lie in wait, that can embed maleware into SPI
flash once Secure Boot is disabled. Even if you were to discover this
(difficult considering most vendors aren't publishing hashes of their
firmware) you'd basically be screwed, not even replacing the boot
drive would get rid of it.


-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to