Regarding dropping support for a LUKS encrypted /boot, one of the comments chimes in with “[but] full disk encryption is mandatory in many environments in Europe for security conformity”.
Surely some user editable data has to be stored in plaintext to be able to boot a system? Does grub.cfg need to be signed by the trust chain to be able to boot?
Unless your UEFI supports reading from an encrypted drive you will at minimum have part of GRUB unencrypted up until the point where you enter a decryption key. so at least initialization, cryptography and filesystem drivers (or module loading) are unencrypted. I hope they are at least secure boot signed else the entire thing is security theater.
But at that point why even encrypt boot and not use something like a signed UKI for decrypting the rest of the disk? That way at least you only have the kernel, its modules and userspace (the initrd usually being a subset of the actual system) as bug/exploit surface instead of also including GRUB and all its modules ontop of that.
On a more serious note, grub is ancient bloatware, it is way overcomplicated for what it does, it's asking to be replaced by systemd-boot distro-wide.
Look at Apple and Microsoft's bootloaders, they are dead simple and have barely changed in 20 years, it makes you wonder how the hell grub was even conceived. It has config files for config files.
grub tries to do the kitchen sink. But we live in a UEFI world now. Boot is simple. None of that is necessary anymore.
> Look at Apple and Microsoft's bootloaders, they are dead simple and have barely changed in 20 years, it makes you wonder how the hell grub was even conceived. It has config files for config files.
It's the GRand Unified Bootloader. The point was to have a single thing that could boot any configuration of any operating system on any platform. It can boot Ubuntu on ARM. It can boot Solaris on SPARC. It can boot Windows on x86_64. Encrypted, RAIDed, from your choice of firmware, on whatever filesystem(s) are around, netboot, reboot, multiboot, you name it, GRUB can do it. And to some degree yes that means it has to be more complicated than eg. BOOTMGR that's only meant to launch one OS and really only wants to do it one way. That said... I do think GRUB 2 really piled on more complexity than was needed; GRUB 0.99 was IMHO essentially the same features but way easier to configure. But even there, I get the appeal of scripting everything to be automagical. I disapprove, but I get it.
If Ubuntu, the most widely used distro, is doing this, it's conceivable that other distros will follow. (Maintainers: "It solved some problems Ubuntu was having, so it will probably solve them for us, too.")
This comment is particularly concerning (as is the functionality regression implied by this new "more secure" approach):
> This means for example, that an encrypted system must use an ext4 /boot partition; it is no longer possible to encrypt the /boot partition.
So, they want to let attackers modify /boot, including grub.conf and the kernel command line? This is better? Look at all these fun knobs attackers will be able to turn!
This lets you disable machine check exceptions + the iommu. That means it'll force people to use a configuration that lets attackers stick a memory probe hardware device into the system + bypass a bunch of hardware security checks. Nice!
I also found module.sig_enforce which lets the attacker disable kernel module signature verification. Sadly, I couldn't find anything that lets you directly load a kernel module from /boot.
However, init.rd lives in /boot. I wonder if its signature is verified or not. At the very least, this approach implies that attackers can piecemeal downgrade stuff early in the boot process.
If you want to avoid the initrd loophole then you will want to look into UKI images. These extend the secure boot signature to include the kernel and ramdisk:
They can turn those knobs anyway, you need something like Secure Boot and measured boot to ensure an untampered environment.
Simple encryption doesn't provide this. An attacker can just as well replace your GRUB.
An encrypted boot partition is extremely rare in practice. It's not done by any installers. It's not the FDE people complaining about this think they've enabled.
13 comments
[ 3.4 ms ] story [ 33.7 ms ] threadSurely some user editable data has to be stored in plaintext to be able to boot a system? Does grub.cfg need to be signed by the trust chain to be able to boot?
But at that point why even encrypt boot and not use something like a signed UKI for decrypting the rest of the disk? That way at least you only have the kernel, its modules and userspace (the initrd usually being a subset of the actual system) as bug/exploit surface instead of also including GRUB and all its modules ontop of that.
On a more serious note, grub is ancient bloatware, it is way overcomplicated for what it does, it's asking to be replaced by systemd-boot distro-wide.
Look at Apple and Microsoft's bootloaders, they are dead simple and have barely changed in 20 years, it makes you wonder how the hell grub was even conceived. It has config files for config files.
grub tries to do the kitchen sink. But we live in a UEFI world now. Boot is simple. None of that is necessary anymore.
It's the GRand Unified Bootloader. The point was to have a single thing that could boot any configuration of any operating system on any platform. It can boot Ubuntu on ARM. It can boot Solaris on SPARC. It can boot Windows on x86_64. Encrypted, RAIDed, from your choice of firmware, on whatever filesystem(s) are around, netboot, reboot, multiboot, you name it, GRUB can do it. And to some degree yes that means it has to be more complicated than eg. BOOTMGR that's only meant to launch one OS and really only wants to do it one way. That said... I do think GRUB 2 really piled on more complexity than was needed; GRUB 0.99 was IMHO essentially the same features but way easier to configure. But even there, I get the appeal of scripting everything to be automagical. I disapprove, but I get it.
> This means for example, that an encrypted system must use an ext4 /boot partition; it is no longer possible to encrypt the /boot partition.
So, they want to let attackers modify /boot, including grub.conf and the kernel command line? This is better? Look at all these fun knobs attackers will be able to turn!
https://www.kernel.org/doc/Documentation/x86/x86_64/boot-opt...
This lets you disable machine check exceptions + the iommu. That means it'll force people to use a configuration that lets attackers stick a memory probe hardware device into the system + bypass a bunch of hardware security checks. Nice!
I also found module.sig_enforce which lets the attacker disable kernel module signature verification. Sadly, I couldn't find anything that lets you directly load a kernel module from /boot.
However, init.rd lives in /boot. I wonder if its signature is verified or not. At the very least, this approach implies that attackers can piecemeal downgrade stuff early in the boot process.
https://uapi-group.org/specifications/specs/unified_kernel_i...
Simple encryption doesn't provide this. An attacker can just as well replace your GRUB.
An encrypted boot partition is extremely rare in practice. It's not done by any installers. It's not the FDE people complaining about this think they've enabled.