3 ms·

An alternative to MokManager/shim is to enroll your own key. You'll also need to convince your kernel package to create a UKI under /efi instead of regular init

An alternative to MokManager/shim is to enroll your own key. You'll also need to convince your kernel package to create a UKI under /efi instead of regular initramfs under /boot, and to sign the UKI with your key. Eg on my OpenSUSE system, the kernel package runs dracut to build the initramfs in /boot, and it's three lines of config to co-opt dracut to build a UKI in /efi and sign it with my key instead. So installing a kernel package automatically creates the UKI in /efi, and systemd-boot automatically notices it on next boot. Debian doesn't use dracut by default, but it does have hooks in /etc/kernel/postinst.d which should let you do the same thing.

Nursie 4y ago
> An alternative to MokManager/shim is to enroll your own key. I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment? Perhaps I have seriously misunderstood!
- vladvasiliu 4y ago
  I'd expect "MokManager" to... manage the MOK. Never used it, though. For one PC whose UEFI was recalcitrant, I've had to use another tool, called "KeyTool". It may or may not be the same thing, but mine let you change multiple kinds of keys, and, in particular, the platform key (aka the "root" key). There are several steps. First, you usually have to put the UEFI in "custom mode", where you install your keys and end with the Platform Key. You typically get some kind of warning when enrolling the PK similar to "this will get the system out of custom mode". I've found the Arch guide to be fairly clear: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... You should be able to adapt it to other systems.
  - Nursie 4y ago
    MOK is short for Machine Owner Key, which is just a way of saying "a key you enroll in your UEFI secure boot variables that is under your control". Or that's what I thought anyway, if it's not actually doing that, and is just enrolling them in some sort of shim-internal DB, then it's a lot less interesting and I'll abandon that approach... I don't necessarily want to change the 'root' PK ... or maybe I do if it's the only way to install a machine-owner trusted key in the real UEFI... I'll look at KeyTool in case it makes saving a key under my control to the db easier/actually work. Though the keytool I'm familiar with is a java pkcs#12 manipulation tool! (on further reading, it looks like shim/mokutil creates a new key-set in nvram, separate to the UEFI stuff, that it manages itself and uses internally. This is not what I was trying to achieve and seems very much like vendor lock. I surely shouldn't need to use shim to boot if I'm signing stuff with my own keys... and it doesn't seem like it has even managed to persist this custom keyset. Back to the drawing board!).
- Arnavion 4y ago
  As you already discovered in the other comment, the root Secure Boot key is the PK, and the MOK is a concept that shim made up. shim was created so that people didn't have to enroll their own PK, if their firmware even let them do that in the first place. Every distro that uses shim was able to get it signed by Microsoft (MS would not sign each and every bootloader in existence, and especially not any version of grub), and then shim does its own verification of the next stage application using the MOK DB.

Nursie 4y ago

> An alternative to MokManager/shim is to enroll your own key. I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment? Perhaps I have seriously misunderstood!

vladvasiliu 4y ago
I'd expect "MokManager" to... manage the MOK. Never used it, though. For one PC whose UEFI was recalcitrant, I've had to use another tool, called "KeyTool". It may or may not be the same thing, but mine let you change multiple kinds of keys, and, in particular, the platform key (aka the "root" key). There are several steps. First, you usually have to put the UEFI in "custom mode", where you install your keys and end with the Platform Key. You typically get some kind of warning when enrolling the PK similar to "this will get the system out of custom mode". I've found the Arch guide to be fairly clear: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... You should be able to adapt it to other systems.
- Nursie 4y ago
  MOK is short for Machine Owner Key, which is just a way of saying "a key you enroll in your UEFI secure boot variables that is under your control". Or that's what I thought anyway, if it's not actually doing that, and is just enrolling them in some sort of shim-internal DB, then it's a lot less interesting and I'll abandon that approach... I don't necessarily want to change the 'root' PK ... or maybe I do if it's the only way to install a machine-owner trusted key in the real UEFI... I'll look at KeyTool in case it makes saving a key under my control to the db easier/actually work. Though the keytool I'm familiar with is a java pkcs#12 manipulation tool! (on further reading, it looks like shim/mokutil creates a new key-set in nvram, separate to the UEFI stuff, that it manages itself and uses internally. This is not what I was trying to achieve and seems very much like vendor lock. I surely shouldn't need to use shim to boot if I'm signing stuff with my own keys... and it doesn't seem like it has even managed to persist this custom keyset. Back to the drawing board!).
Arnavion 4y ago
As you already discovered in the other comment, the root Secure Boot key is the PK, and the MOK is a concept that shim made up. shim was created so that people didn't have to enroll their own PK, if their firmware even let them do that in the first place. Every distro that uses shim was able to get it signed by Microsoft (MS would not sign each and every bootloader in existence, and especially not any version of grub), and then shim does its own verification of the next stage application using the MOK DB.