On 4/7/22 10:28 AM, Lennart Poettering wrote:
On Di, 05.04.22 17:38, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) 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.
Couldn't the other Fedora change about adding file signatures to the RPM
installed files be used to close this hole?. Enabling some policy at
boot that disallows execution on code not signed that is inside the
initrd. I think all code copied to the initrd must come from Fedora
packages, maybe the only exception are third party kernel modules.
Note: It appears cpio doesn't support extended attributes [1]
[1] https://bugzilla.redhat.com/show_bug.cgi?id=771926
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.
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
