On 2020-08-06 08:04:56 +0100 (+0100), Nikolaus Rath wrote: > On Aug 05 2020, Jeremy Stanley <fungi@yuggoth.org> wrote: > > On 2020-08-05 20:30:59 +0100 (+0100), Nikolaus Rath wrote: > >> On Aug 04 2020, 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. > >> > >> Wouldn't such an attacker simply modify the (necessarily unencrypted) > >> initrd such that it stores the decryption key for the attacker the next > >> time you enter it? > > > > How would this attacker generate the new initrd signature so that it > > still validates correctly? > > I didn't know this was validated these days. Still, couldn't they just > reconfigure/reinstall Grub so that it doesn't validate the initrd? The idea is that UEFI/BIOS checks the signature for GRUB before executing it, and does so instructing GRUB to verify the signature for its config. GRUB then checks the signatures on the kernel and initrd before handing off control. To alter GRUB or its configuration or the kernel or initrd ultimately (in theory, barring bugs like the "Boot Hole" vulnerability everyone was talking about over the weekend) you'll have to guess the BIOS password or have access to reflash it with your own. Ideally this tampering also invalidates cryptographic attestation for the entire chain, which the user should then be able to detect. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature