The point of DKMS is to compile kernel modules on the same host where they'll be used, so it needs the private key to be accessible. And isn't DKMS a rather common thing on Linux, e.g., for Nvidia drivers and for VirtualBox?
On Arch most DKMS packages have a separate package that is compiled directly against the stable kernel (and some against the lts kernel). IIRC they all don't support loading with SB though since the keys that are embedded in the kernel for other modules are discarded after the kernel build.
This is to say, its not impossible that those can be signed from the distro. Just Arch doesn't.
Check out "sbctl" by Foxboron, it's a UEFI key and signature manager [1] that's pretty nice.
But other than that I agree with you there, I wish that upstream kernel builds would be signed by the distro for secureboot usage. Maybe this should be part of the archlinux-keyring package?
But that relies on having the private key available locally, so it doesn't help with the scenario discussed here. Ideally, you'd want to sign the image on a different machine than the one booting it.
True, but that kind of also requires some way of distributing the bootable binaries, e.g. via netboot image via a TFTP server.
I usually store these keys on a LUKS encrypted flash drive. Not the best opsec, but at least good enough to prevent this kind of malware from spreading around. Can't update the kernel without the flash drive though :D
> I usually store these keys on a LUKS encrypted flash drive. Not the best opsec
Why would it not be the best opsec?
I replied to your other comment suggesting encrypting your local signing keys. I am not sure if I would use a flash drive though, why not just using the local disk?
I haven't looked into the tooling much, but does it at least support pkcs11? That way you'd at least be able to store the key on a smart card or Yubikey.
Yes. Edit /etc/dkms/framework.conf, set mok_signing_key to something like "pkcs11:id=%01", and mok_certificate to point to a file containing the certificate. You can extract the certificate using eg "pkcs11-tool -r -y cert -d 01 > .../cert.der".
I don't know. I actually asked myself this very thing while typing the above comment, but I'm too busy/lazy to look it up.
One issue I can see with this, though, is that if the malware is already present on your system and can run things, nothing would prevent it from hijacking the modules or the boot image before they're signed.
