Why not? I configure my fully encrypted system then I sign my boot loader. If someone tempers with the signed files I’ll find out because system won’t boot. I can add out of tree modules and not have a care of what Microsoft thinks of the code I’m running because they certificates are all mine.
I find it great that I can do that. Its like SELINUX… kinda a pain in the ass to setup and maintain but once you’ve learned how to use it things are nice.
That right there is a big reason many don’t do like what you are doing. Furthermore SCALE is important, IT admins at businesses tend to administer more systems than homelab people would(i don’t know your situation though). And those same IT people that homelab their work would tend to operate their homelab in the same(or very similar) ways as they would at work. Though they might experiment with ways that they could make Work go easier, which is a different matter altogether.
Indeed, that is a great example of why many who do like you are doing, do that. However, many people(including the mentioned IT peeps) want things to “Just Work” out of the box, no fiddling required. Which means that they aren’t looking to add kernel modules or otherwise modify any part of the boot process that would necessitate signing the kernel themself.
Point is Windows, Fedora and Ubuntu have their kernels signed. It just works. Normies are covered.
Enterprise rarely need this on their devices since most of their stuff is signed by Microsoft. They have money to spend on some solution.
Anyone aiming to run other flavors of Linux should have no issue running sbctl to enroll and sign their stuff.
So going back to the point, what we have now even though imperfect is leagues better than the old days of booting from whatever its on the few first bytes of the disk.
Seems like my 2023 Dell laptop is in the clear. I do remember a few UEFI updates hitting some months ago.
Wonder if the GB motherboard on my personal desktop is fine, but I have SecureBoot off always on that.
Still safer than non-secure boot. Not as secure as should be.
When you enroll your own keys, do you remove already enrolled roots of trust?
With this flaw, someone could use those TESTING NOT FOR PRODUCTION keys to sign a malicious kernel which should validate against it, defeating the whole point of secure boot.
This. And with A.I. botnet farms searching the net for vulnerable PC’s this is even more worrisome if your network AP isn’t secured against attacks.
Situation:
Attacker uses known management engine vulnerability to push rogue firmware update. Then it sits and waits for internet connectivity anywhere on the machine (or preloads rogue kernel) and as soon as that bootloader/os is detected it pushes a factory signed “do not trust” rogue kernel and waits for you to boot up and enter your decryption key (since most kernels are still by default in plain text thanks to distros making zero effort to mitigate this)
Open firmware is the only solution. Encourage tinkering and focus on a open security model. We don’t need proprietary DRM like systems.
I never much cared for TPM when it first came out and I likely never will. The Consortium didn’t approve of it for the benefit of the user. They approved of it because it was big bux for them and precious little benefit to the end user. How many times have those keys been hacked, broken, and/or corrupted? Windows is having a hay day with it, rendering many PCs, some not even 3 years old since the release of Windows 11, forcing people to toss their “old” computers simply because they don’t measure up to TPM requirements. The “security” argument is so utterly lame that it’s ludicrous. Linux users are not exempt from this chicanery either. When will people learn that security keys are a fail?
I wouldn’t mind implementing my own custom keys, but the process to me seems so arbitrarily difficult. Would also be nice so that I could sign my ventoy drive with this and essentially lock booting only to that device. Problem is that I feel like there’s not a huge return with SecureBoot. It can easily be disabled in the UEFI. And UEFI passwords seem to have inconstent, sometimes shoddy implementations across MB manufacturers.
Most cryptographic transactions are. It is because of the Two Generals problem. How can you trust that the information is correct, well, by following these procedures.
We could make it easier but the process right now is as easy as it gets without compromising trust.
Yeah. I am just too stupid to figure out how to properly do it atm. When I first started out with Linux (circa 2016-18), I thought that SSH PKI was mind boggling. Now, it seems like the easiest thing in the world.
The TPM can prevent someone from taking your disk out and trying to access it in another computer because the keys are tied to your hardware. If the whole chain is secure it makes difficult to impossible for a physical attacker or a root kit to get into your system.
Geez guys there are lots of misconceptions about secure boot in this thread. It’s being pushed by Microsoft so it must be bad right?
Again is it perfect? No. But is it better than simple BIOS boot? Hell yes.
And no, some motherboard manufacturers doing a mess with the keys does not mean the whole idea should be scrapped out. If anything there should be a way to audit and attest the vendor default certificates.
Which requires open firmware, period. It’s the only way to be sure.
The days when firmware was a simple microprocessor instruction set to make it easier to write drivers, is long since gone. These days UEFI is an embedded OS all in it’s own right, and if it is an entire OS, then maybe we should start thinking about a more open firmware?
I’m not saying necessarily that all firmware needs to be open, closed modules may definitely exist. But any closed system cannot be proven to be secure, decades of research proves this, so perhaps it is time to start thinking in more open terms? Just my $0.02
Two notes:
Or a thorough external audit, with access to source code,
But then, who could be trusted with that?
AMD could fill this niche so well. If only someone knew their CEO, they could focus on supporting coreboot by collaborating with UEFI motherboard vendors. The UEFI support is already there.
Open software has bugs too. Open firmware would not solve this problem.
You’d still have bugs, you’d still need users to do firmware updates. Zero net change really.
Oh, shit i guess we need to scrap TLS, SSH and disk encryption too!
This. The whole “well there was a bug found! its entirely pointless! get rid of it!” attitude is pathetic really.
Do people abandon linux any time there’s a kernel bug? No. Patch it, fix the issue, move on.
Secure boot gives the option to establish a root of trust very early in the boot sequence. Don’t want it? Disable it. Don’t like that microsoft require it for Win11 now? Run a different OS. You have plenty of options.
In any case, this is the disclosure of a private key, as has happened with SSH, which has killed open source software repositories in the past. This is not a flaw with secure boot, this is user error (admittedly where “user” is one of the secure boot developers) - not a conceptual problem.
Circling back to this… if you read the actual article, the whole problem this time around was the open source repository for this project posting private keys into the source code repository.
Open source won’t fix that, in fact putting the code in the open in this instance made the problem worse.
Github and other public repositories need to be scanning for key material more effectively, as per : A robot leaked my SSH keys – alexwlchan
Developers (both open source and closed source) also need to be more mindful with their key material, also per above…
While FOSS does nothing for the technical part of Security… It does a whole lot for the trust part of Security.
FOSS is not a silver bullet, but any solution that cannot be audited by a third party is automatically garbage tier security. It is that simple. If you cannot audit the solution you can also not be sure the solution works as intended.
Is this Sufficient for Security? No. But it is definitely Necessary to achieve security. But it is true, this is one criteria of several that needs to be fulfilled.
Security starts with auditable solutions, and open firmware is one of the best ways to make things auditable.
Not when it can be remotely turned back on or the entire UEFI just gets compromised by a rogue management engine (who’s modules are lazy-signed so anything can be plugged in with the lazy keys) plus disabling secure boot is not an option if you are serious at all about security (due to the problem mentioned above)
I think normally UEFI wouldn’t be such an issue if it were left to be offline but the fact that both AMD and Intel run proprietary management engines, which have constant access to the internet, keeping UEFI closed-source is a huge problem.