The real issue is that by default, if secure boot is enabled, you won’t be able to boot up into bazzite or whatever in order to run that command.
So the user experience will be worse now, because instead of just installing and running, Linux users have to disable secure boot, boot and install their distro, run that enroll command, and then reenable secureboot. And lots of people are going to give up at step 1, and leave secureboot off.
EDIT: could they just make this part of the install process? Could they make it like a thing that runs on first boot, if you can only do it from within the kernel/boot loader that is to be authorized?
I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn’t care what it cost others. But we’ll likely never know what their true intent was.
I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose.
Edit: see princessnorah’s comments below for more details, but it is a lot more hands on, which prevents malware abusing it.
In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.
I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn’t care what it cost others. But we’ll likely never know what their true intent was.
They originally tried to design Secure Boot where the OS could never add a key, that would have made sure it never worked for Linux. It wouldn’t have prevented Linux from running as long as Secure Boot was disabled, but IIRC a lot of people were worried that manufacturers would end up making it mandatory and it does generally complicate the install process for new users disabling it.
I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose.
It just calls the mokutil command which is what’s generally used on Linux to enrol keys, it’s what the official NVIDIA docs recommend to install the keys for the driver kernel modules. It’s just four lines and two of those are echos to make things look prettier for the user.
In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.
I mean, everyone is already using a pre-signed “shim” released by Microsoft, that’s what this whole situation is about, the certificate for that is about to expire. If RedHat, Canonical, SUSE and Debian all had their own certificates included by manufacturers, they could have released their own “shims” for other downstream distros to use and kept things entirely within the Linux ecosystem. Yes, it would have increased the risk of a signing key getting loose, but I personally trust RedHat still more than Microsoft, even after all the stuff they’ve done.
Still, it’s entirely possible to securely get an OS key into your devices keystore. If you download an ISO onto a trusted device and check it’s SHA256 hash against the one provided on the distros website, you can verify its authenticity. Then flash it, disable secure boot on the target system, install it without giving it internet, enrol its keys using similar steps to what the Bazzite script is doing (there are plenty of guides online for various distros) and only then give the new system internet access, the chances of something nefarious worming it’s way in are very very slim.
It’s also all about your personal threat vector. If you’re just an average joe or joette then this is going to be a perfectly acceptable method because no one’s going to want to access your system that badly. Corporations are data-hungry, but it’s the same rule as bike locks, as long as yours isn’t the weakest one on the rack, they’re gonna steal a different bike. However, if you’re an activist, journalist or (god forbid) a politician, then you should be buying a device that has the new windows key in the BIOS, and not disabling secure boot.
Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.
The other way keys could be securely installed would be for the distros to produce a uefi “addmykey” binary, with their keys baked in to the binary. They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.
100% agree on the risk profile though, far too many people think they are more important than they really are. Realistically, most of us aren’t worth the effort to individually break into our computers.
Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.
They already thought of that. You don’t just hit accept, you then have to type out a password that you set when you run mokutil. So if malware runs it instead, the user just won’t know the password at all.
They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.
Yes, that’s exactly how it has worked up until now, more or less. The issue is that the original Microsoft SB key is expiring and old hardware, that’s no longer getting firmware updates by the manufacturer, then the new key isn’t going to be added ever. If those distros had a key included as well, they likely would have made its expiry a lot longer, because they support hardware for a lot longer. Microsoft doesn’t care because Win11 can’t run on most of these devices anyway.
Oh, well, if it requires a password that is pretty much solved. The original commentor made it seem a lot less hands on.
I was under the impression that the shim let OS’s boot all the way up, and that it was just a standard part of the boot process, I was suggesting instead that the signed binary only let’s you add a new key, which you can then use to boot without the shim.
Doesnt help when the key expires though.
Thanks for the additional info, greatly appreciated.
That should exactly fix the problem.
The real issue is that by default, if secure boot is enabled, you won’t be able to boot up into bazzite or whatever in order to run that command.
So the user experience will be worse now, because instead of just installing and running, Linux users have to disable secure boot, boot and install their distro, run that enroll command, and then reenable secureboot. And lots of people are going to give up at step 1, and leave secureboot off.
Microsoft is counting on that
EDIT: could they just make this part of the install process? Could they make it like a thing that runs on first boot, if you can only do it from within the kernel/boot loader that is to be authorized?
I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn’t care what it cost others. But we’ll likely never know what their true intent was.
I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose.Edit: see princessnorah’s comments below for more details, but it is a lot more hands on, which prevents malware abusing it.In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.
Its just not an easy problem to solve.
They originally tried to design Secure Boot where the OS could never add a key, that would have made sure it never worked for Linux. It wouldn’t have prevented Linux from running as long as Secure Boot was disabled, but IIRC a lot of people were worried that manufacturers would end up making it mandatory and it does generally complicate the install process for new users disabling it.
It just calls the
mokutilcommand which is what’s generally used on Linux to enrol keys, it’s what the official NVIDIA docs recommend to install the keys for the driver kernel modules. It’s just four lines and two of those areechos to make things look prettier for the user.I mean, everyone is already using a pre-signed “shim” released by Microsoft, that’s what this whole situation is about, the certificate for that is about to expire. If RedHat, Canonical, SUSE and Debian all had their own certificates included by manufacturers, they could have released their own “shims” for other downstream distros to use and kept things entirely within the Linux ecosystem. Yes, it would have increased the risk of a signing key getting loose, but I personally trust RedHat still more than Microsoft, even after all the stuff they’ve done.
Still, it’s entirely possible to securely get an OS key into your devices keystore. If you download an ISO onto a trusted device and check it’s SHA256 hash against the one provided on the distros website, you can verify its authenticity. Then flash it, disable secure boot on the target system, install it without giving it internet, enrol its keys using similar steps to what the Bazzite script is doing (there are plenty of guides online for various distros) and only then give the new system internet access, the chances of something nefarious worming it’s way in are very very slim.
It’s also all about your personal threat vector. If you’re just an average joe or joette then this is going to be a perfectly acceptable method because no one’s going to want to access your system that badly. Corporations are data-hungry, but it’s the same rule as bike locks, as long as yours isn’t the weakest one on the rack, they’re gonna steal a different bike. However, if you’re an activist, journalist or (god forbid) a politician, then you should be buying a device that has the new windows key in the BIOS, and not disabling secure boot.
Having read up a bit more on
mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.The other way keys could be securely installed would be for the distros to produce a uefi “addmykey” binary, with their keys baked in to the binary. They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.
100% agree on the risk profile though, far too many people think they are more important than they really are. Realistically, most of us aren’t worth the effort to individually break into our computers.
They already thought of that. You don’t just hit accept, you then have to type out a password that you set when you run
mokutil. So if malware runs it instead, the user just won’t know the password at all.Yes, that’s exactly how it has worked up until now, more or less. The issue is that the original Microsoft SB key is expiring and old hardware, that’s no longer getting firmware updates by the manufacturer, then the new key isn’t going to be added ever. If those distros had a key included as well, they likely would have made its expiry a lot longer, because they support hardware for a lot longer. Microsoft doesn’t care because Win11 can’t run on most of these devices anyway.
Oh, well, if it requires a password that is pretty much solved. The original commentor made it seem a lot less hands on.
I was under the impression that the shim let OS’s boot all the way up, and that it was just a standard part of the boot process, I was suggesting instead that the signed binary only let’s you add a new key, which you can then use to boot without the shim.
Doesnt help when the key expires though.
Thanks for the additional info, greatly appreciated.
Ah yeah, I didn’t explain the process fully, my apologies.
So how do we fit AI into this scheme 🤔