Hi, On Tue, 4 Aug 2020 12:31:04 +0000 Jeremy Stanley <fungi@yuggoth.org> wrote: > 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. to be protected from this threat, you'd also have to disable the platform key and instead also sign the kernel and grub yourself. Otherwise a malicious party can just boot anything signed with the platform key, which should be more than enough to do whatever malicious thing they want to do. Even if you do that, I don't think you've actually locked out malicious parties with physical access. The grub configuration (both on the boot partition and the EFI partition) and the initrd are AFAIK with the current configuration not signed. You would also have to protect your UEFI settings from being tampered with, to prevent a malicious party from just disabling secure boot entirely. However, that should be quite trivial as most UEFI firmware has the ability to protect the configuration by password. To sum it up, I think having a mechanism to automatically sign DKMS modules with the MOK would be a valuable step towards protecting against this threat, but I think to actually have full protection we would also need automatic mechanisms to: * sign installed kernels with the MOK, * sign the installed GRUB with the MOK and configure it to verify all loaded files with <some gpg key> (taking care that a malicious party can't just use the grub console to disable signature checking), * sign generated grub configurations with <some gpg key>, * sign generated initrds with <some gpg key>. Maybe some or all of these things are already possible with current tooling, so please feel free to correct me if this is the case. Regards Sven
Attachment:
pgpCXWfeuX4Ul.pgp
Description: OpenPGP digital signature