[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

enable Linux kernel gpg verification in grub and/or enable Secure Boot by default

1 Like

Possible to use check_signatures=enforce on non-EFI such as amd64?
https://lists.gnu.org/archive/html/help-grub/2019-12/msg00006.html

2 Likes

Guaranteeing initramfs integrity during Secure Boot

2 Likes

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

1 Like

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.

1 Like

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.

1 Like

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?

3 Likes

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:

https://github.com/systemd/systemd/issues/13816#issuecomment-545428989

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.stub to 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) https://lwn.net/Articles/784674/

1 Like

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.

1 Like

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.

https://www.phoronix.com/scan.php?page=news_item&px=GRUB-2021-Secure-Boot-Issues

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]