Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
https://arstechnica.com/security/2023/12/just-about-every-wi...
https://arstechnica.com/security/2024/07/secure-boot-is-comp...
Anyway, it's good to hear that I probably don't have anything to worry about.
I'm not understanding how it's the desktop Linux users who have to deal with poor security.
Lot of good that will do you when Linux users will curl | bash most any garbage.
The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting).
> thinking about whom to trust and primarily sourcing their software from the distro package manager
So "app store" is the wave of the future?
The days of Linux users using magic healing crystals to protect themselves from malware are long over. Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you.
On Linux Mint if you run a program without granting any extra permissions it can: Record your mic, record your camera, record your screen, steal your browser history/ cookies/passwords, alias sudo or show a fake update dialog to collect the user's password to elevate to root, see if you copied a crypto address and replace it with a similar looking one owned by the attacker, encrypt all of your files, send any sensitive pictures or documents to the attacker, etc.
The existence of a 50 year old concept of file permission is not good enough to combat the modern security problems users can encounter.
For example, you want your users' laptop hard drives to be encrypted - but also you have users who regularly forget their passwords? With bitlocker their hard drive can decrypt itself, so they only need to remember their windows login, which you can reset remotely.
You give laptops to your field workers, who have full physical access and would love to play video games or access netflix when work puts them in a hotel over night with nothing to do? With secure boot you can keep your precious spreadsheets locked down, even if they're willing to boot from USB sticks or swap the hard drive.
And perhaps most importantly, it has "secure" in the name. So the corporation's IT security auditors will like to see it turned on even if they have only a vague understanding of what it does.
Earlier versions of Windows were a much bigger threat to adoption of Windows 8 than Linux was.
I have never used it on my gaming PC and Windows doesn't seem to care.
Most people experience this via Windows, which automatically sets up that chain of trust so that you can know you've not had a rootkit injected somewhere. In other cases it may be Linux or something more exotic booting, and it requires some management by whoever is operating the device, but that comes with the benefit of knowing that if one of our devices has got to the point of decrypting it's storage we can be reasonably confident that it hasn't been tampered with, and so we can trust it to send good data.
With custom hierarchies, it's a bit more compelling. But it's a lot of work to maintain.
Code has bugs. There's any number of critical vulnerabilities in Linux, Windows, MacOS that have allowed bypass of all security features - does that mean all security features remain security theatre?
The cost in terms of freedom/flexibility and reliability/longevity is very high. But we're told, this is necessary, it's the only way to guarantee the security of the poor user. But if in practice the security wasn't actually guaranteed, for most motherboards over most years, due to pretty big dumb oversights ... was it worth the extreme costs? The cost of losing compatibility with older or newer software/hardware, of losing convenient repairs and recovery? Nope.
You sold your soul for "guaranteed security" of securing the entire boot and runtime from the lowest level hardware up ... and didn't really get it anyway.
They could've used a time stamping service to include a signed timestamp in the binary to compare the expiry date against, but that still leaves the system unbootable after the time stamping certificate expires in the far future.
Besides, a hacking group powerful enough to steal Microsoft's Secure Boot private key will likely be able to steal a timestamping private key from a certificate authority as well.
SecureBoot would have been better off with certificates that never expire. That's not a problem in cases where users (or organisations) manage their own hosts, since they can just changed the certificate when the previous one is no longer valid or leaked or whatever.
In practice, SecureBoot rolled out with a single CA for everyone, one controlled by Microsoft. This provides little value for anyone—restricting your computer to "only boot stuff signed by a third party" doesn't really protect from attackers in any way. They'll just boot into one of the many programs signed by MS. But because a single CA is used globally, you want expiration so as to roll them over every few years. But remember: there's no way to have a reliable clock. And so, we have the mess that we have.
The grand majority of Linux users could disable SecureBoot tomorrow and their system's security would not change in any meaningful way.
- on a mobo the motherboard provider signs the PK
- there's only one PK
- the PK signs one or more KEK, like "Microsoft Corporation UEFI CA 2011"
If that understanding is correct, can I add myself the new "Microsoft Corporation UEFI CA 2023" (the one that expires in 2038: I think that its name) the same way I can enroll new keys in the dbx? (say my own signed keys?)If I add the new Microsoft key myself, shall it be as a KEK or in the dbx?
Will motherboard manufacturer release new firmware, with the new Microsoft key already signed? In that case, shall be a KEK ?
Basically instead of thinking, as TFA suggests: "Let's not worry about anything, everything shall be fine and keep working because keys expiration date aren't enforced", can I pro-actively enroll the new Microsoft key myself?
P.S: I don't drink the SecureBoot kool-aid but something has to be said about having a Linux unikernel (kernel+initramfs) signed and enforced by SecureBoot. And SecureBoot does at least somehow work. Source: I modified on bit of my kernel and had a SecureBoot error and the kernel refused to boot. You can try it for yourself.
As well as the new root certificates in db, which are used to decide whether signed code will execute or not, there will be a new signed Microsoft key for KEK. This isn't involved in the boot process, but is required for Microsoft to be able to sign further revocation updates. The article is discussing the db case, and if you want to ensure things signed only with the new key will boot on your system, you would want to add them to db.
Microsoft can sign a db update themselves (since there's a valid Microsoft key in KEK and db updates need to be signed with a key in KEK), but KEK updates need to be signed with PK. Microsoft doesn't own PK, so adding the new KEK requires the system vendor produce an update signed with their PK.
If you are in a position to enroll the new keys then you should enroll the new db keys if you want new binaries to be guaranteed to boot, and add the new KEK if you want to be able to apply future Microsoft-signed dbx updates.
Users should absolutely be able to install the db update by hand if they choose to, but it's late and I don't have the commands to hand. I'll write another post on this soon.
So, dumb question: If the expiry dates are not enforced, why rotate the certificates at all? The only consequences of Microsoft introducing new keys seems to be that compatibility with old software and systems will over time become worse. But what's the upside - or the actual threat model this is defending against?
M95D•20h ago
EVERYBODY wants that! And I mean ABSOLUTELY EVERYBODY! Updates are now mandatory everywhere, in both Windows and Linux, and GPU manufactureres would LOVE to make the old cards obsolete, even if technically the new cards aren't much better.
So expect to see the old certificate invalidated quickly and automatically, in the name of security, of course!
michaelt•19h ago
Secure Boot is a fine thing if you're a huge corporation and want to harden laptops against untrustworthy employees, or you've got such a huge fleet of servers they go missing despite your physical security controls, or you're making a TiVo style product you want to harden against the device owners. But when the user is the device owner? Doesn't do much.
trelane•19h ago
This sentence just makes me so sad
observationist•16h ago
Throw in jail time for decision makers. Lets make markets honest with real incentives.
necovek•16h ago
Do you own a phone that's easily rooted? Who else does?
What about your WiFi routers? Internet modem? AirTags? Smart home appliances?
esseph•14h ago
necovek•13h ago
Still, my point was not about running a rooted phone with unlocked bootloader (secure boot disabled on a pc equivalent), but whether if this is possible accounts in your purchasing decision.
tsimionescu•8h ago
necovek•8h ago
charcircuit•7h ago
necovek•2h ago
Full disk encryption on a device you have full control of is sufficient.
Containerization helps if you install untrusted apps.
Not having root helps if you install untrusted apps (either vulnerabilities/exploitable or malicious) as root.
fsflover•3h ago
userbinator•10h ago
Terr_•15h ago
It's still a problem if manufacturers force ExploitationOS on the device I bought, but it's not-as-bad when everyone can collaborate to disable the exploitation-parts.
https://www.eff.org/issues/dmca
immibis•14h ago
jon-wood•2h ago
M95D•19h ago
In the end what matters is always money. Always.
What brings more money? TiVo or buyer-owned device? You think 5% of technically competent potential buyers would make a difference when the 95% illiterate users will just replace the product no questions asked?
It started as a fight against piracy and half-competent users that break their own systems (and the company's systems too, like you said). But slowly the industry sees that there's more money to be made if the same technology can provide a belivable argument in right to repair and planned obsolescence court cases.
[1] https://github.com/melontini/bootloader-unlock-wall-of-shame
II2II•16h ago
The reality is that PC's address the needs of a fundamentally different market than "TiVo"s or even mobile phones. While most could, and probably should, be using secure boot noone seems to be eager to take away the option to disable it.
Lammy•15h ago
Hello from 2013, and here you go!
https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot
https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...
LeoPanthera•10h ago
Lammy•9h ago
tsimionescu•8h ago
Plus, tablets are not PCs. People are happy with tablets and phones as locked devices. They are not happy with PCs as locked devices, and have not accepted such control, maybe outside the MacOS ecosystem.
fsflover•3h ago
mjg59•8h ago
fc417fc802•8h ago
Microsoft perennially makes small movements in that direction. Reduced control over the OS and attempts to exert control over the software ecosystem. I assume they're still trying to push consumers towards Windows S mode devices.
Kernel mode anticheat that won't run on systems that aren't attested. Streaming platforms that won't serve up decent quality streams. Even if you don't notice the pot being boiled there are those of us that do.
mjg59•8h ago
fc417fc802•7h ago
jand•7h ago
Tangent: To me that sounds like a reference to the "frog boiling" story. This has been debunked [1], a healthy frog will not remain in a gradually heated pot of water. We need a better analogy for this.
[1] https://en.wikipedia.org/wiki/Boiling_frog
fc417fc802•7h ago
supportengineer•17h ago
keyringlight•17h ago
immibis•14h ago
citizenpaul•16h ago
Its one of my interview questions these days. What device will I be issued?
If its a chromebook I know that no matter what they say they don't really care about the postion.
jon-wood•2h ago
spydum•16h ago
crazygringo•15h ago
bongodongobob•12h ago
tux3•17h ago
Certainly. Just one problem: Modern consumer BIOS interfaces are graphical and your GPU is off.
ThePowerOfFuet•17h ago
mjg59•16h ago
tsimionescu•8h ago
mjg59•8h ago
tux3•6h ago
If you let arbitrary code run before you start checking, you don't have a secure boot chain.
tpoacher•16h ago
mschuster91•15h ago
A decent Secure Boot implementation together with a BIOS/EFI password at least makes the life of US CBP or similar thugs wanting to use my devices against me much more difficult.
And no, that's not an imaginary threat, certainly not under this administration which has come under fire multiple times for first detaining and then deporting random tourists.
swagmoney1606•8h ago
a96•1h ago
xg15•5h ago
jimmaswell•17h ago
tomhow•7h ago
Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks* around it and it will get italicized.*
https://news.ycombinator.com/newsguidelines.html
M95D•1h ago
tomhow•24m ago