It seems the issue here is that initramfs is not signed, which makes this attack possible.
If it is signed and an evil maid modifies the initramfs itself, it will break the secure boot process and the user will be notified that their system has been tampered with. This should indicate that the secure boot protection is working.
If initramfs is not signed and it drops to the debug shell, then the attacker can make any changes to your system without it affecting secure boot, since it has already passed the protection. At least that’s my understanding when I read this.
Depends on the OS, but you can generally have mkinitcpio handle generating new UKIs after updates and also have it trigger something like sbctl to re-sign images.
This is true, unfortunately some Linux users have been conditioned to “just turn off Secure Boot” without understanding what this actually means and entails.
If someone has physical access then surely they can change the initramfs without having to use the debug shell?
It seems the issue here is that initramfs is not signed, which makes this attack possible.
If it is signed and an evil maid modifies the initramfs itself, it will break the secure boot process and the user will be notified that their system has been tampered with. This should indicate that the secure boot protection is working.
If initramfs is not signed and it drops to the debug shell, then the attacker can make any changes to your system without it affecting secure boot, since it has already passed the protection. At least that’s my understanding when I read this.
That makes sense. Would a signed initramfs be possible though? Since it’s usually rebuilt after most system updates?
Depends on the OS, but you can generally have
mkinitcpiohandle generating new UKIs after updates and also have it trigger something likesbctlto re-sign images.This is true, unfortunately some Linux users have been conditioned to “just turn off Secure Boot” without understanding what this actually means and entails.