Last Tuesday, loads of Linux users—many running packages released as early as this year—started reporting their devices were failing to boot. Instead, they received a cryptic error message that included the phrase: “Something has gone seriously wrong.”
The cause: an update Microsoft issued as part of its monthly patch release. It was intended to close a 2-year-old vulnerability in GRUB, an open source boot loader used to start up many Linux devices. The vulnerability, with a severity rating of 8.6 out of 10, made it possible for hackers to bypass secure boot, the industry standard for ensuring that devices running Windows or other operating systems don’t load malicious firmware or software during the bootup process. CVE-2022-2601 was discovered in 2022, but for unclear reasons, Microsoft patched it only last Tuesday.
…
The reports indicate that multiple distributions, including Debian, Ubuntu, Linux Mint, Zorin OS, Puppy Linux, are all affected. Microsoft has yet to acknowledge the error publicly, explain how it wasn’t detected during testing, or provide technical guidance to those affected. Company representatives didn’t respond to an email seeking answers.
I think you’re misunderstanding the purpose of Secure Boot. It’s not designed, nor very good at, preventing physical access. It’s designed to verify the authenticity of the code you are booting each time, most generally to prevent remote attacks. Think of it more like how HTTPS works. The reason you commonly have to install new keys when installing Linux is because there are separate ones for the bootloader, the OS, and kernel modules. GRUBs is generally already in the database. The OS can be hit and miss, Canonical generally has theirs included for example. Then there’s the kernel modules. If they were built and included in binary form, they’re usually signed with the same key as the OS. But if they’re built locally, say when you install NVIDIA driver’s, then they’re signed with a local key, which has to be enrolled. So it’s similar to a self-signed HTTPS certificate. A lot of routers use those, and browser’s will throw a big warning you have to click through. It’s the same with Secure Boot. For example, if a virus tries to build a malicious kernel module, it will throw the same enrollment screen, which would let you know something’s up if you didn’t initiate it. There also has to be a password, that you set in userspace, and then re-enter on the enrollment screen, confirming that it’s a requested action.
Disabling other keys won’t prevent someone from simply entering the bios and disabling Secure Boot first if they have physical access, which would let them boot anything. If you want to prevent that, then the methods you would generally use is setting a system password in the BIOS it asks for each boot, or disabling other boot options (or the boot menu depending on the computer) and setting a BIOS password. However, if you’re trying to prevent people from booting other OSes as a way to protect your files from being accessed, well someone could just take the drive out with physical access. The best practice there is to encrypt the drive with something like BitLocker, FileVault or LUKS/dm-crypt (basis of many distros full-disk encrypt features).
Edit: You could also have Secure Boot enabled, delete every other key and set a BIOS password if you wanted too I guess. I haven’t tried, nor read of anyone trying too.
