Hacker News Reader

Comment by StillBored | Hacker News Reader

This big mistake though was back when all this was being enabled on PC's, the linux vendors out of fear that the rest of the industry would lock them out, standardized on shim and the MS certificates in the firmware. Thus requiring MS to sign the first stage of every linux install/boot rather than both doing that, as well as defaulting to an environment where the distros would boot in UEFI 'setup mode' enroll their own cert/key chains during the first provision/boot, and then permanently switch to user mode. Had they done that, this entire article would have been just about meaningless as all those test keys would have been replaced the moment the machine was installed.

So today a decade+ later there still isn't a standard way to automatically enroll a linux distribution's keys during initial install in any of the distributions (AFAIK).

View on HN

that's out of date for at least 6yrs. most Linux distro already support many ways to generate your own keys and automatically sign your kernels and modules. and bioses have ways to enter "user mode" so you can upload your PK etc.

but still, since the attack for this to be worth is out of this world rare... very few orgs bother to even document it in the main guides because it gives zero protection and infinite support load

I don't think you are understanding my point.

The distro installer should, if it detects setup mode, automatically be asking the user if they wish to replace the all the existing keys and enroll distro supplied certs, keys and dbx entries. Except none of the distros have this infrastructure built, outside of their dependence on Microsoft.

And no, none of this is needed if all you want is to be able to self sign a kernel/etc because its possible to install a MOK key to shim, but that isn't the point, the point is that the vast majority of linux users aren't setup to protect a cert/key chain from an attacker. Which is the entire reason for secure boot. If your attacker is sophisticated enough they will be stealing the signing keys from your machine/org and signing their own updates. Which is why MOK and self signing is a mistake for ~100% of Linux users.

ah yes. good point.

it doesn't help that the team (guy?) doing all the systemd unification for those features now work for Microsoft anyway.

Arch has a pretty useful key enrollment tool that I'm sure exists on other distros too. Only command line, though. There's also tooling for enrolling a custom key database if your firmware doesn't accept the standard API by creating a bootable key management update tool with your preferred keys.

There's a guide for both approaches here: https://wiki.archlinux.org/title/Unified_Extensible_Firmware.... You'll need to make sure whatever distro you use has the right hooks to sign the boot images after each upgrade (i.e. an apt callback rather than a pacman callback) if you're not using Arch, of course.

Using the sbenroll tool, the process is three commands (generate keys, enroll keys, sign current bootloaders) plus whatever extra BIOS interfacing logic your computer needs on top of normal secure boot stuff like unlocking the BIOS through a password.

As I pointed out to the other respondent, I don't think people are understanding what i'm saying. I'm not suggesting that its not possible to manually enroll, or self sign (which should come with a giant warning that it basically invalidates much of the security if the signing keys aren't protected with something hopefully more complex than a keyboard entered password).

Basically the installers should be replacing the existing certs and keys, with distro supplied ones which are maintained along with global DBX entries by the distro itself, with a distro supplied KEK/etc where the private keys are stored in a high security environment not available to most users.

Its really the kind of project the linux foundation should be sponsoring so the infra could be shared cross distro.

Reply on news.ycombinator.com