On Tue, 2020-08-04 at 12:31 +0000, Jeremy Stanley wrote: > 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. Ubuntu already does this by default IIRC - dkms enrolls a new MOK cert, with the private key stored in /var/lib. For my Debian machines, my personal MOK private key is stored on my Yubikey, and I sign dkms-built modules manually whenever needed. It's quite simple to use linux-kbuild-foo/scripts/sign-file with a Yubikey or any other pkcs11-enabled hardware token: /usr/lib/linux-kbuild-foo/scripts/sign-file sha256 "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000; token=SomeName" /path/to/public/cert.pem /path/to/kmod.ko I don't think it's something that can be reasonably automated for general usage though, due to interactive nature of the signing process, and most importantly the whole setting up of the key + token + enrollment which are not exactly user-friendly processes. Canonical's approach seems to be the most user-friendly it can be, assuming one is willing to give up the benefit of being unable to alter the firmware/running kernel without physical presence. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part