On 2020-08-04 13:52:04 +0200 (+0200), Thomas Goirand wrote: > A few months ago, it took me a long long time to figure out how to do > this and write it in this wiki page: > https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key > > This works very well, but I wonder if we could automate this by having a > hook in DKMS, so that any DKMS rebuild would also sign the DKMS modules. > Indeed, it's very annoying that I have to resign the modules manually > whenever the kernel increases version (in my case, I need to sign the 3 > virtualbox kernel modules...). > > Maybe we could have a standard path where to store the machine key, and > DKMS would use it? Maybe having a /etc/default/dkms where to configure this? > > Of course, I am aware that this probably is a security problem. Someone > more knowledgeable than me with secure boot could explain why, and how > to mitigate the risks, how to store my machine owner key, etc. But for > me, usability is more important, and secure boot is still nice. Maybe > there's a way to get this safe, like encrypting the MOK and prompt for a > password every time? > > Thoughts anyone? The whole point of signing the kernel and modules is so that you can detect and block kernel-level subterfuge. This comes in a couple of ways: 1. the administrator unwittingly downloading and installing a kernel/module which has been tampered with by malicious forces, or 2. an attacker installing a kernel/module through some local exploit of system security. That first risk is mostly also mitigated by secure-APT or similar mechanisms to verify the packages you're retrieving over the network are what you think they are. If your signing key is available on the local system, then you can't effectively guard against the second risk because an attacker with access to replace your kernel or add a kernel module now likely also has access to the key to sign them. The usual paranoid solution is to not keep the signing key on the system which trusts it, and likely not even compile kernels/modules on that system, but instead build and sign them elsewhere on a tightly-controlled system and copy them in. Basically, if you're going to stick the key on the system which is trusting things signed by it, then I'm not quite clear on why you'd bother with trusted boot at all... it's just creating useless complexity for you. Okay, so for systems to which a malicious party may gain physical access (or remote console access) there's sort of a third risk this addresses. A special case of the second risk really. *If* you're also encrypting the filesystem on which that signing key resides (via LUKS or similar) then this might keep you safe from someone with access to replace the kernel or initrd on the unencrypted boot partition... but only if they can't unlock the decryption key for the FS which holds the signing key of course. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature