- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
Follow up to: “Something has gone seriously wrong,” dual-boot systems warn after Microsoft update
SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we’ve seen real world examples of malware wanting to do that (Black Lotus did so using a vulnerability in the Windows bootloader, but a vulnerability in grub would be just as viable for this). Viewed purely from a security perspective, this was a legitimate thing to want to do.
…
The problem we’ve ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it’s worth noting that grub is signed by individual distributions, not Microsoft, so there’s no externally introduced lag here). Microsoft’s stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself. Unfortunately, as is now obvious, that didn’t work as intended and at least some dual-boot setups applied the update and that distribution’s Shim refused to boot that distribution’s grub.
…
The outcome is that some people can’t boot their systems. I think there’s plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they’re updating those and updating the security generation to match, because otherwise they’re shipping a vector that can be used to attack other operating systems and that’s kind of a violation of the social contract around all of this.
From one of the comments:
Emphasis mine.
Are people that cucked now that they’re like “yes, please daddy, lock me out of my own machine”?
The only charitable read of this is the end-user bypassing controls on company-supplied computers.
Of course that doesn’t mean that they won’t also shove secure boot, hw lockouts, DRM, etc on regular consumer laptops as well.
[This comment has been deleted by an automated system]
As an admin… end users are generally fucking stupid with regards to technology. I don’t trust the average individual to operate a spoon.
Then you’ll be hopefully setting a UEFI password for them and end of story. Instead of wanting a corporation to lock out everyone of the machines that they own, making sure that no one on earth can boot unsigned Linux either, for example.
You can’t trust users to make informed decisions about cybersecurity as most users don’t have the necessary background knowledge, so won’t think beyond this popup is annoying me and has a button to make it go away and I am smart and therefore immune to malware. Microsoft don’t want Windows to have the reputation for being infested with malware like it used to have, and users don’t want their bank details stolen. If something’s potentially going to be a bad idea, it’s better to only give the decision to people capable of making it an informed decision. That’s why we don’t let children opt into surgery or decide whether to have ice cream for dinner, and have their parents decide instead.
The comment you’re quoting was replying to someone suggesting a warning popup, and saying it would be a bad idea, rather than suggesting the secure boot UEFI option should be taken away. You need at least a little bit more awareness of the problem to know to toggle that setting.
Is that why they introduced “recall?”
No, that is an entirely unrelated bad decision. It being okay to not have a popup to opt out of secure boot when it does its one job and notices you’re about to run insecure code in kernel mode doesn’t make every other user-hostile thing Microsoft ever does magically okay.
For me there are users, admins and owners, and all levels should have escalating rights to mess with the system. I don’t want a user to have access to security settingsn nor being able to mess with registry or similar stuff. I would prefer a user not being able to do more than read any important part of the HDD too
Yes, they are.