On Sa, 25.06.22 20:43, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > It’s necessary for secure boot to actually be meaningful in > > practice. I expect that people who care about secure boot > > will want this. > > I don't. I only care about secure boot enough to bootstrap a Free > platform. Secure Boot is generally not designed as a tool to provide > security unless you rip out all the certs and use your own > exclusively. At that point, you can do whatever you want. This is FUD. Of course SecureBoot can improve security, if you make proper use of it, as it provides some level of offline security, i.e. that you can leave your laptop unsupervised for a minute and make it for attackers a lot harder to backdoor the boot process. So far Linux distros didn't use it for that though — what was actually implemented was the bare minimum to make systems behave as before, not taking benefit of any of the real security benefits it offers. And yes, if all you want is the status quo ante then SecureBoot is just a PITA. But maybe in IT security landscape of 2022 we shouldn't build systems anymore the way we built them in 1990, but make things harder to backdoor. And SecureBoot helps you with that — if one actually makes proper use of it. Or in other words: the fact that initrds are not signed on Linux distros defeats the whole point of SecureBoot, but unsigned initrds is not an inherent idea of SecureBoot, but just a misfeature of Linux distros, and is what we should actually fix. > 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. What you are writing above is about as smart as saying that signed RPM packages are bad because they make it a bit harder to enroll your own RPM signing key to install your own signed packages... Signing and authenticating the code is a good thing to protect systems – it's a good thing if we can do so for the boot code too as we boot. 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
