Possible to use check_signatures=enforce on non-EFI such as amd64?
https://lists.gnu.org/archive/html/help-grub/2019-12/msg00006.html
maybe this could work:
Assuming FDE on host, for Whonix encrypt /boot by default and have users enter a passphrase at grub to unlock it? Now nothing can get at initrd or kernel. then unmount /boot after login
One thing : Grub 2 does not support LUKS 2
That doesnât fly easy. /boot, kernel, initrd needs to be updated. It regularly gets updated through apt dist-upgrade. Unmounting /boot would break that.
The suggest approach could work inside VM if the host managed the VMs disk /boot parition but that is cumbersome having the host mount the VMs disk and modify it. Also security risk of the host mounting the VM disk.
KVM VMs could specific kernel, initrd, kernel parameters on the host by pointing to files available on the host. That could make kernel and initrd trusted inside the VM (assuming the host to be trusted). That would be similar to Qubes dom0 kernel vs Qubes VM kernel. Qubes dom0 kernel has some disadvantages and itâs planned to make that a non-default, i.e. make VM kernel the default.
It is clunky!
on updates, users would have to make sure to remount and then update their grub, grub config and initramfs themselves and grub may have to be installed to the /boot/efi partition.
An attacker can just mount /boot again.
Ah wait, nvm. It would still need the password for decryption.
When we build a custom kernel anyways (and disable module loading?) we could maybe just remove the initramfs completely?
I made an issue on the systemd github repo a while ago about GPG verification in systemd-boot (similar to GRUB) and got this response:
If you trust Secure Boot, then you can already use the same Secure Boot (e.g. with your own keys in PK/KEK/db) to secure the kernel and initramfs. A very common method is to use systemdâs âEFI stubâ
linuxx64.efi.stubto create a combined (kernel+initramfs).efi image that will be verified by Secure Boot as a single unit.
and another reply on the Microsoft leaking the keys issue:
SecureBoot already does all this, and you can flush out Microsoftâs keys from the firmware and replace them with your own.
i.e. secureboot can verify the initrd and we can remove the leaked keys.
Verification of the initrd is now even more important as weâre moving more things into it such as apparmor-profile-everything and sysctl-initramfs.
Also, verifying just the kernel, initrd and bootloader isnât the best. Ensuring the integrity of those has very limited advantage when the attacker has already compromised the entirety of userspace and has highly privileged persistence. Android/ChromeOS have a far more complete implementation which verifies all of the base OS.
Thereâs some interesting comments on this thread too by Daniel Micay (yet again - heâs everywhere) The return of the lockdown patches [LWN.net]
Debian made major progress on SecureBoot. They would surely appreciate a helping hand signing and verifying initrd too.
I guess at best complicated instructions could be provided how to remove these keys from BIOS settings (EFI). Unless pre-configured hardware is sold with a pre-installed operating system.
Recent sec reports show that enabling secure boot is a trade-off between security and adding attack surface. Itâs arbitrary code execution and memory corruption type of bad.