4
1
Are boot.img, initrd, and vmlinuz adequate or should the entire contents be hashed? I am not familiar enough with the Linux boot process to answer this with confidence myself.
IAmAGuest
Posted 2013-08-04T01:05:32.733
Reputation: 41
What files from the /boot partition, in addition to the MBR, must be hashed in order to detect an "evil maid" attack against LUKS-encrypted Linux?
Answers
1
The safe bet would be to hash all files on /boot (the kernel, system map, MBR and the boot loader configuration) - however who is to say the evil maid won't simply just replace the hashes? So now you need to implement GPG so you can sign & verify the hash file. But what if the evil maid subverts GPG?? Arghhh ...
So, I suggest if you're really worried about that evil maid, a better solution is to keep /boot on a removable keychain type USB device on your belt. It's only needed to boot after all. I use a nifty one on an elastic tether thingy.
Nanzikambe
Posted 2013-08-04T01:05:32.733
Reputation: 627
One should consider using UEFI with SecureBoot or TPM. Because once the system has executed an untrusted bootloader or kernel, it's too late. – Franklin Piat – 2015-03-28T13:22:57.927
UEFI has several Ring0 exploits that safety is no longer a safety net :( I personally keep /boot backed up on a usb AND have the system fully shutdown on non use and build my kernel images to be HOST only without hardlinks (so the crypt is not gonna boot without the boot mounted (which without a usb in is not happening) – linuxdev2013 – 2015-06-12T01:24:29.097
2I'm not qualified to answer, but I'd imagine that you would additionally need to validate the boot sector to prevent an alternative boot sequence being used. I expect that you would ideally want to hash and check everything except the LUKS encrypted partition. Of-course, this won't help if someone can plant a hardware key logger. – davidgo – 2013-08-04T01:53:32.593