←back to thread

Linux and Secure Boot certificate expiration

(lwn.net)
253 points pabs3 | 7 comments | 18 Jul 25 03:53 UTC | HN request time: 0s | source | bottom
Show context
saidinesh5 ◴[18 Jul 25 06:54 UTC] No.44601960[source]▶
Just out of curiosity, how good is the secure boot experience these days?

I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.

replies(11): >>44602000 #>>44602120 #>>44602279 #>>44602520 #>>44602559 #>>44602593 #>>44602696 #>>44602761 #>>44602773 #>>44603004 #>>44607063 #
bravetraveler ◴[18 Jul 25 07:01 UTC] No.44602000[source]▶
Signature maintenance for modules can be fully automated. Enrollment requires navigating a mildly-intimidating interface a single time to accept the new PKI.

Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)

replies(1): >>44602333 #
1. mormegil ◴[18 Jul 25 07:59 UTC] No.44602333[source]▶
Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?
replies(3): >>44602388 #>>44602396 #>>44602630 #
2. bravetraveler ◴[18 Jul 25 08:10 UTC] No.44602388[source]▶
Aye, though an evil maid has higher barriers and more paperwork in a DC.

I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.

3. ChocolateGod ◴[18 Jul 25 08:11 UTC] No.44602396[source]▶
Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).
replies(2): >>44602912 #>>44603086 #
4. michaelt ◴[18 Jul 25 08:59 UTC] No.44602630[source]▶
> Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it?

One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"

But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.

Of course if your server has a KVM attached, you can still do this remotely, I guess.

5. the8472 ◴[18 Jul 25 09:55 UTC] No.44602912[source]▶
With a UKI the initramfs gets signed too, doesn't it?
6. vbezhenar ◴[18 Jul 25 10:25 UTC] No.44603086[source]▶
There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though.

1. You can sign and verify initramfs, it's supported by bootloaders.

2. You can merge kernel and initramfs into UKI and sign the whole image.

I don't know why that's not implemented.

replies(1): >>44623428 #
7. ChocolateGod ◴[20 Jul 25 09:45 UTC] No.44623428{3}[source]▶
For UKI I imagine a big hurdle is the size of the images (given /boot/efi is usually only big enough for bootloaders, not kernels and initram) and custom kernel modules (e.g. Nvidia).

There was some systemd work on a spec for a boot partition to extend the efi partition for storing kernel images and initramfs, but I don't think any distro currently defaults to it on.

I think hibernation is currently also broken, since the hibernation file is stored unencrypted by default and thus can't be used with secure boot.