Best way to deal with versioned kernels

[ericonr]

So, unlike Arch, Void has versioned kernels, which look like linux-5.4.53_1.efi, for example, in the case of a UEFI bundle generated by dracut. This means two things in the current version: each new kernel version will have to be added to the database manually, and old kernel versions that are removed at some point will lead to complaints from sbctl, though not outright failures. I've thought of a few solutions:

For the new kernel part:

• have a distribution level hook that adds the kernels to the list for you, nothing needs to be done in sbctl
• have an option to sign all files in the ESP, potentially unsafe

For the old kernel part:

• have a command line flag to automatically remove files that don't exist any more from the database

I hadn't realized this is an issue because I use a custom initramfs, so it's versioned a bit differently, and gets bumped less often.

[Foxboron]

and old kernel versions that are removed at some point will lead to complaints from sbctl, though not outright failures.

Can probably implement a sbctl clean or sbctl remove-old-files or something to check if files exist and remove them from the database if they dont.

As for the general issue, I'm unsure. /usr/lib/modules/$(uname -r)/vmlinuz could maybe work? But I'm unsure how to bake this into sbctl in an understandable way. Add a switch for --find-kernel-img?

[ericonr]

Can probably implement a sbctl clean or sbctl remove-old-files or something to check if files exist and remove them from the database if they dont.

This sounds like a reasonable solution!

As for the general issue, I'm unsure. /usr/lib/modules/$(uname -r)/vmlinuz could maybe work? But I'm unsure how to bake this into sbctl in an understandable way. Add a switch for --find-kernel-img?

Hmm I don't think this would work.

• It isn't generic enough: Void still stores kernels in /boot, Arch stopped doing so and now stores them in /usr/lib/modules
• It doesn't get the right version: if I'm booted into 5.7.X and I get an update for 5.7.(X+1), I want sbctl to sign the new kernel, not the current one

At least for the current kernel hook mechanism in Void, the hook has knowledge about the kernel version, which means it can determine the name of the kernel images/UEFI bundles it needs to sign. This is a solution that depends on the distribution implementing proper integration for sbctl.

On the other hand, having sbctl scan the ESP and find the files it needs to sign works, but then it might sign a file it shouldn't. Having a flag for sign-all like --sign--all-esp would be a switch for this behavior, but I'm not sure sbctl should enable this behavior at all.

[Foxboron]

There is no way for us to template up the linux kernel name? Add sbctl.conf with KernelFormat=linux-$pkgver_$pkgrel or something? Add full path and allow globs maybe?

[Foxboron]

Or we have an AllowList/DenyList for the --sign-all-esp-yolo function?

[ericonr]

Either a list of kernel formats or explicit allow/denys would work, I guess, but then I think we'd have to define the threat model.

• An attacker with enough privileges to put a file in the ESP from a running system likely also has enough to access and use the keys in that same system, so there is very little protection from this attack vector in any situation
• An attacker with physical access / with access to the disk from a compromised system which doesn't have the secure boot keys (a situation where someone dual boots into an installation that only signs kernels) can put the file in the ESP and hope that they get the AllowList pattern correct and that signing the file works.

These are the two scenarios I can think of for an attack where someone counts on an automatic signing feature. For the second one, I would have sbctl pring a very big warning about files that it signed because of the --sign-all-esp-yolo flag. Ideally it wouldn't be added to the database either, so it would always generate warnings, but I think that would make for poor UX.

[swsnr]

@ericonr I am sorry to bump and mention, but I am playing with sbctl these days, and would like to understand what this issue is about, mostly to know what I'm signing up for with sbctl. You wrote about dracut in your in initial comment:

So, unlike Arch, Void has versioned kernels, which look like linux-5.4.53_1.efi, for example, in the case of a UEFI bundle generated by dracut

I use dracut myself, and wonder how you envision the interaction between sbctl and dracut, especially since dracut can also sign EFI binaries.

In my tests I used sbctl sign -s only for the bootloader (systemd-boot) binary and the grml rescue system kernel, and then pointed dracut to the sbctl keys under /usr/share/secureboot and let it sign its generated binaries. I tested this setup in a libvirt/qemu found and had no issues, but I haven't yet used it over a longer time or on real hardware.

Is this how it's supposed to be with sbctl and dracut?

[Foxboron]

dracut only really uses sbsign on the images. That's it. Nothing wrong with it but it's not really flexible in my opinion. I want key rotation, support for smartcards and signing EFI binaries outside of what concerns the initrd generator.

I think dracut with kernel-install hooks would be the correct approach (at the moment) until sbctl can be made aware of versioned kernels.

[swsnr]

@ericonr I understand, the first paragraph at least. The second paragraph, not such much :see_no_evil: : What's a "kernel-install hook"?

I am very sorry if that's a stupid question; you see dracut --force --uefi --kver $(uname -r) already puts an EFI binary into a place where systemd-boot picks it up automatically, so the whole setup pretty much worked right away from the start and I never had to grok the details at all or understand how this glues to together.

I'd not like to trespass on your time though; please do feel free to skip the explaining; I'd really just like to know whether using sbctl sign -s for the bootloader (and sbctl sign-all after bootctl update) and dracut --force --uefi --kver $(uname -r) (with uefi_secureboot_* in dracut.conf pointing to the sbctl key and cert) for the kernel is an ok way to use sbctl currently.

In any case thank you very much for the quick answer, and for this tool. It's really a huge step forward; I was staring at the Arch Wiki Secure Boot instructions for hours and already prepared to give up on the idea of secure boot, when I found this tool, and had secure boot up and running (in a VM) within minutes. Thanks a lot :pray: :clap:

[ericonr]

Yes, using sbctl for key management / bootloader signing and just pointing dracut at the keys works fine. One possible contrib/ file to add to sbctl could be a file to drop in /etc/dracut.conf.d that points to the location of the UEFI keys.

I am not currently using dracut's signing because I'd like to be able to completely remove sbsigntools from my system at one point, and just let sbctl handle the whole thing. But that does make me lose some automation, atm ;)

[dkwo]

I'm also interested in a clean function.