I am following this guide on full disk encryption, including /boot. Section 4 involves placing a key that can decrypt /boot and / into the initramfs image contained in /boot, so that once you unlock /boot with GRUB, Linux can automatically unlock /boot and /. It states:
After all for LUK1 the volume key can already be found by userspace in the Device Mapper table, so one could argue that including key files to the initramfs image – created with restrictive permissions – doesn’t change the threat model for LUKS1 devices. Please note however that for LUKS2 the volume key is normally offloaded to the kernel keyring (hence no longer readable by userspace), while key files lying on disk are of course readable by userspace.
When I read "while key files lying on disk are of course readable by userspace", I think this isn't a problem because to protect against the native OS, the key file has restrictive permissions, and to protect against a live OS, the disk is encrypted. So in order for "key files lying on disk [to be] readable by userspace", or readable at all, you would first have to unencrypt the disk. Which, if an attacker knows the password for that, then all hope is already lost. (although I suppose there are side channels like monitoring data in RAM as the initramfs is loaded)
But is there something I'm missing? Doing Section 4 doesn't lower security for LUKS1, but what about LUKS2? Does doing Section 4 compromise your security?
I suppose what I need to know to answer this is (my apologies if this should be a separate question)- when not using Section 4 to avoid password prompts, there are three times you need to enter your password: #1, when GRUB unlocks /boot, #2, when Linux unlocks /, and #3, when Linux unlocks /boot (more explanation on that here). When doing Prompts 1 and 3, are GRUB and Linux both comparing against the same cryptsetup keyslot(s)? Because if so, prompts 1 and 3 are basically the same check, the same password will always succeed on both of them. So there's really only 2 password prompts instead of 3, and so doing Section 4 will only cause you to lessen protection on /, not /boot. That's a less severe security hit.
Thank you all!
/boot. Would you still put your rootfs passphrase into a keyfile? If not, how would encrypting/bootmake it okay? Once there is a keyfile, it can be leaked. It creates a new attack vector; up to you what to make of it.--pbkdf=pbkdf2. cryptsetup will use the keyring then if that's relevant to you.--type luks2instead, and add the--pbkdf=pbkdf2option to section 4 step 2, or is there more? Do you know any resources that go over how to ensure the key is offloaded to the kernel keyring, so I can delete the key in userspace? I can ask in a new question if necessary. Thank you very much!!