On 2023-03-10 13:48:21 +0000 (+0000), Stephan Verbücheln wrote: > Encryption per se does not protect against modification, I am aware of > that. That is even more true for disk encryption where the encrypted > data block has to fit into the physical disk block, so there is no room > for a MAC or signature. However, in combination with a filesystem like > btrfs which checksums everything, it is providing some protection, even > though it was not designed for that purpose. Okay, so you're wanting to rely on encrypted /boot as an incomplete alternative to checking file signatures, because the current attestation solutions are also imperfect. Keep in mind that checksumming isn't providing protection from coherent modification of the decrypted filesystem and checksums, it's just protecting against someone blindly modifying the encrypted blocks. If they have physical access to your system sufficient to modify firmware or add hardware without you noticing, then encrypted /boot is pretty pointless against such an actor. > Apart from the fact that UEFI Secure Boot is an overly complex monster > which is basically broken[1] by design, my understanding of it is also > that it does not protect configs, initramfs etc. in /boot. It only > protects the kernel image and loaded modules. > > [1] > https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/ Well, it's not as if encrypted /boot is protecting you from the attacks described in that article either. Someone with that level of access to your system can quite easily record/copy your decryption keys, or simply wait until you've unlocked your sensitive data. > In addition, files in /boot like the initrd are generated individually > and may contain files not limited to what someone puts into /boot > intentionally. In contrast to /boot/efi, /boot does not only contain > static files delivered by the distribution. Sure, if you're concerned that sensitive information is being put in /boot sufficient to warrant the additional work of protecting it from disclosure when someone steals the device or gets their hands on the drive after disposal, then by all means go ahead. It's just not usually worth that amount of additional complexity. It comes down to basic cost/benefit analysis, and deciding what threats you reasonably want to invest in defending against. I'm certainly not saying there's *never* a reason to encrypt /boot, but people who feel they need to do so aren't involved in improving tools and automation sufficiently to make it convenient to set up either. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature