Defending against the evil maid, how to handle removal of the /boot partition
Finally figured it out. This still feels really hacky and dirty because the system is never aware that /boot
may not be mounted and you'll have to manually mount it before doing anything that might write to it (think system updates, etc), but other than that it works perfectly.
- prepare your flash drive with a single partition with the boot flag set on it. You may run
shred -n 1 -v /dev/sdX
on it to erase it completely, including any previous boot sectors; once that's done runfdisk
to create a partition andmkfs
your filesystem of choice on it. - mount your flash drive somewhere,
/mnt/boot
or even/newboot
will do just fine. - move over everything from
/boot
to the flash drive withmv /boot/* /newboot
. - edit your
/etc/fstab
and change the original boot partition's UUID (or create an entry if there isn't any) to match the one of your flash drive. You can get the UUID withlsblk -o name,uuid
. Also add thenoauto
option so that the drive won't be mounted automatically to be able to remove it as soon as the system starts booting (once the kernel is loaded) without risking corrupting the FS on it. - unmount the original boot partition and the flash drive (
umount /boot && umount /newboot
) and mount the flash drive; if your fstab entry is correct you can just runmount /boot
and it'll automatically mount it based on the UUID specified in the fstab. - regenerate your bootloader's configuration to reflect the new partition's UUIDs and "physical" position, for GRUB the flash drive will actually appear as the first hard drive in the computer (
hd0
). If you're okay with using the default GRUB configuration scripts supplied by most distros, you can rungrub-mkconfig -o /path/to/grub.cfg
and it'll generate the file according to the currently mounted partitions and/or fstab. Note that for CentOS 7, the correctgrub.cfg
is actually located in/boot/grub2/grub.cfg
.
When doing any operation that may access the boot partition, connect your USB stick and run mount /boot
. Once done, you may run umount /boot
. Note that the latter command can take moments to complete because it's flushing the buffers to the disk (the disk itself is slow so the kernel buffers some write operations to speed things up).