4 ms·

Ubuntu wants to strip some of GRUB features in 26.10 for security purposes

52 points by dryarzeg 7mo ago

gorgoiler 7mo ago
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?
- ahartmetz 7mo ago
  When I hear full disk encryption, I think of what I'm using: Using the encryption feature of the disk with a password / keyphrase prompt built into the system firmware (UEFI). It is 100% transparent to any software. The only major downside is that you need to trust the hardware manufacturer (and their FIPS certification), which is fine for my purposes, but might not be fine for state secrets or extremely valuable trade secrets.
  - pona-a 7mo ago
    I don't know if FIPS standards have improved, but combining my priors about products boasting FIPS and manufacturer code quality in general, I would actively not trust it with any data, full expecting it either leaks them, corrupts them, or somehow both.
    - ahartmetz 7mo ago
      Works just fine for legal ass coverage
- NekkoDroid 7mo ago
  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.
longislandguido 7mo ago
Have they replaced it with grub-rs yet? 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.
- plagiarist 7mo ago
  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.
  - longislandguido 7mo ago
    systemd-boot is only similar to systemd in name; it started as another project and was renamed.
    - mirashii 7mo ago
      It’s been merged into the systemd project, so one must assume that the systemd maintainers have some level of influence over it.
      - longislandguido 7mo ago
        Remind me why I'm supposed to care who the maintainer is for a piece of software that runs for a few seconds then gets tf out of the way.
        logicchains 7mo ago
        Because they're going to try to use it to make it impossible for you to run an operating system that isn't spyware.
Zardoz84 7mo ago
I glad that I moved to green pastures... Aka Debian.
- hedora 7mo ago
  This sort of crap keeps getting upstreamed into Debian. Consider devuan for your next machine. I've switched almost all my linux boxes to it, and it's great.
  - opengrass 7mo ago
    Up voted for Devuan. Getting services to work is a hassle but really easy after using the same template for start/stops.
- theandrewbailey 7mo ago
  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.")
  - tmtvl 7mo ago
    Yea, like when Ubuntu switched from System V init to Upstart. Or when they created Mir to replace X. Or when they created Snap for distro-independent packages. Or when they forked GNOME into Unity. ...man, when did Ubuntu start losing every battle they fought?
    - estimator7292 7mo ago
      When they started slipping ads into aptitude. I think that's when most of us started giving Canonical the side-eye
hedora 7mo ago
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! https://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt 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.
- izacus 7mo ago
  All those switches and we still can't disable kernel lockdown when hibernation is enabled with secure boot.
- evan_a_a 7mo ago
  encryption does not protect against malicious modification; authentication does.
- jburgess777 7mo ago
  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: https://uapi-group.org/specifications/specs/unified_kernel_image/ https://uapi-group.org/specifications/specs/unified_kernel_i...
- Avamander 7mo ago
  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.
unmayx 7mo ago
[dead]

52 points by dryarzeg 7mo ago

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?

ahartmetz 7mo ago
When I hear full disk encryption, I think of what I'm using: Using the encryption feature of the disk with a password / keyphrase prompt built into the system firmware (UEFI). It is 100% transparent to any software. The only major downside is that you need to trust the hardware manufacturer (and their FIPS certification), which is fine for my purposes, but might not be fine for state secrets or extremely valuable trade secrets.
- pona-a 7mo ago
  I don't know if FIPS standards have improved, but combining my priors about products boasting FIPS and manufacturer code quality in general, I would actively not trust it with any data, full expecting it either leaks them, corrupts them, or somehow both.
  - ahartmetz 7mo ago
    Works just fine for legal ass coverage
NekkoDroid 7mo ago
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.

longislandguido 7mo ago

Have they replaced it with grub-rs yet? 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.

plagiarist 7mo ago
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.
- longislandguido 7mo ago
  systemd-boot is only similar to systemd in name; it started as another project and was renamed.
  - mirashii 7mo ago
    It’s been merged into the systemd project, so one must assume that the systemd maintainers have some level of influence over it.
    - longislandguido 7mo ago
      Remind me why I'm supposed to care who the maintainer is for a piece of software that runs for a few seconds then gets tf out of the way.
      - logicchains 7mo ago
        Because they're going to try to use it to make it impossible for you to run an operating system that isn't spyware.

Zardoz84 7mo ago

I glad that I moved to green pastures... Aka Debian.

hedora 7mo ago
This sort of crap keeps getting upstreamed into Debian. Consider devuan for your next machine. I've switched almost all my linux boxes to it, and it's great.
- opengrass 7mo ago
  Up voted for Devuan. Getting services to work is a hassle but really easy after using the same template for start/stops.
theandrewbailey 7mo ago
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.")
- tmtvl 7mo ago
  Yea, like when Ubuntu switched from System V init to Upstart. Or when they created Mir to replace X. Or when they created Snap for distro-independent packages. Or when they forked GNOME into Unity. ...man, when did Ubuntu start losing every battle they fought?
  - estimator7292 7mo ago
    When they started slipping ads into aptitude. I think that's when most of us started giving Canonical the side-eye

hedora 7mo ago

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! https://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt 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.

izacus 7mo ago
All those switches and we still can't disable kernel lockdown when hibernation is enabled with secure boot.
evan_a_a 7mo ago
encryption does not protect against malicious modification; authentication does.
jburgess777 7mo ago
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: https://uapi-group.org/specifications/specs/unified_kernel_image/ https://uapi-group.org/specifications/specs/unified_kernel_i...
Avamander 7mo ago
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.

unmayx 7mo ago

[dead]