> Demi Marie Obenour <demiobenour@xxxxxxxxx> wrote: >> On 6/25/22 07:56, Roberto Ragusa wrote: >>> On 6/19/22 22:54, Sharpened Blade via devel wrote: >>> >>>> Use unified kernel images by default for new releases. This can >>>> allow for the local installation to sign the kernel and the initrd, >>>> so the boot chain can be verified until after the uefi. >>> >>> How big is the demand for this kind of lockdown? As a >>> since-last-century Linux user, I'm choosing Fedora exactly to NOT >>> have all this signing/trusted boot complications on my systems and I >>> do not see a reason to turn Fedora into Android (or, worse, iOS). tl;dr: that's not what Secure Boot is; packed kernel+initrd images may be in the cards As one of the people responsible for getting Fedora's shim signed and therefore making Secure Boot work, I feel it's necessary to clarify that we don't agree with any of the misinformation in this thread: Secure Boot is not lockout. Secure Boot is not designed or even intended to keep you out of your own machine. The entire trust model assumes that if you have physical access, it's your machine: you can manipulate keys, and even turn Secure Booting off. If you don't own the machine... well, then you're an attacker, it's designed to keep you out, and as I'm not a blackhat, you'll get no help from me :) How you configure your own hardware, should you choose to do so, is your own business and I won't tell you how to do that. But as it adds a tangible security benefit, and even if you're doing custom module/kernel/etc. builds, it's really not very difficult to add your own key and sign. Secure Boot can be thought of as primarily a way to avoid attacker persistence on the system. Supposing someone otherwise roots the machine, by restricting boot targets to known good (as determined by machine owner or distro vendor), we make it much harder to (for example) deploy a bootkit, or load a malicious kmod. This isn't perfect (see the original post), but it's clearly better than not having it, and problems like "the initrd isn't signed" are eminently solvable. While I will not be responding to all the dangerously incorrect things that have or can be said, here's a sample reply: Neal Gompa <ngompa13@xxxxxxxxx> writes: > I only care about secure boot enough to bootstrap a Free platform. False dichotomy. Secure Boot isn't nonfree, nor is the Fedora ecosystem somehow decoupled from it. > Secure Boot is generally not designed as a tool to provide security Wildly, dangerously incorrect. (And it's not a tool - many components work together to enable it, including the kernel.) > unless you rip out all the certs and use your own exclusively. At that > point, you can do whatever you want. If you're doing custom builds, you're of course encouraged to use your own certs. How you configure your own machine is, again, your business. > Most PCs are poorly designed to handle doing this procedure, and it's > too easy to accidentally break the computer entirely by doing so. It's > just not worth it. Groundless speculation, and not correct. > I treat Secure Boot purely as a compatibility interface. We need to do > just enough to get through the secure boot environment. Again, this misunderstands the security boundary. Be well, --Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
