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.
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.
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:
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.
I'd like a better boot manager but I sure as hell do not want systemd cancer to spread any further. Especially not after Poettering has started a remote attestation company.
> 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.
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?
44 comments
> 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.
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.
https://uapi-group.org/specifications/specs/unified_kernel_i...
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 makes you wonder how the hell grub was even conceived
I'm wondering how much was interop with trying to boot multiple operating systems off the same disk?
> 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.
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?