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:
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.
In the last 5 years I had too many times when I need to spend literally hours to properly boot the same OS it was installed with. Booting the Win*-like is just a matter of chain loading for CSM or straight pointing to bootmgr.efi on UEFI systems.
lilo was great. Elilo was not maintained so now the only usable option is refind. Grub trying to be a smart ass and numbering things with its own nomenclature is ... funny.
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.
What fearmongering has the anti-systemd crowd been selling you? Genuinely curious because I wish I wasn't running systemd. My perspective is that the things they (we?) are saying are basically correct. But the service manager works well enough that most distros have accepted the downsides.
> it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
Can you prove beyond a reasonable doubt that they intend to force this on you without any way of disabling it, or that they have already done so? Because unless they plan to do this (and you have concrete proof of such and not just "well they could do this" claims) or they have already done it across a significant portion of the Linux distribution ecosystem (and no, distros voluntarily switching to systemd is not forcing anyone to do anything), this is fearmongering. Simple as that.
> it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
Considering it changes nothing on what they actually work on on systemd I would give this a yes. Every time I hear "they will do this or that" it just never really happened. So far it feels more like "the boy who cried wolf" than "slippery slope" to me. But maybe I am missing something?
A lot of the devs have always here and there added features for secure/measured boot and image based OSes and things that make them more usable to daily drive (hermetic /usr/, UKIs, sysext, portable services, mkosi, DDIs, ...). A lot of the things make image based systems more modifiable/user accessible without compromising on the general security aspect.
If they really wanted to lock in Linux users to a single blessed image from them they would have had a better chance when Lennart was working at Microsoft (which generally is the only preinstalled CA) instead of starting a "competing" company (they are targeting a different niche from what I understand).
This, and locking down everyone to a single blessed Linux distro would be... Rather difficult given how widespread Linux is and just how many distros exist. It is one thing for each distro to decide "Hey, let's use systemd". Gnome requires it but that's Gnome; there is nothing stopping you from using XFCE, or I3, or KDE, or... It is a totally different thing to make every Linux distro stop working (and have said distro go along with that) because that distro isn't the "blessed" one. Microsoft can pull this off because they're Microsoft and they have total control over one of the most dominant operating systems. Apple can pull this off because they're Apple and control everything from the hardware upwards. Linux is neither of these. I would go so far as to argue that the BSDs have a better chance of pulling off something like this than Lennart does. RedHat may have a lot of influence in the Linux world, but it certainly doesn't have some secret god mode switch it can flip and universally make every distro conform to it's wants and desires.
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?
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.
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.
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.
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.")
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?
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-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.
encryption does not protect against malicious modification; authentication does.
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_i...
All those switches and we still can't disable kernel lockdown when hibernation is enabled with secure boot.
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.
> 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?
In the last 5 years I had too many times when I need to spend literally hours to properly boot the same OS it was installed with. Booting the Win*-like is just a matter of chain loading for CSM or straight pointing to bootmgr.efi on UEFI systems.
Grub does suck yes. The only boot loader on uefi I like is refind https://www.rodsbooks.com/refind/
Bring back Lilo!
lilo was great. Elilo was not maintained so now the only usable option is refind. Grub trying to be a smart ass and numbering things with its own nomenclature is ... funny.
Personally, I miss blessing my iBook with “holy penguin pee”:
https://github.com/jeffv03/yaboot/blob/master/ybin/ybin#L902
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.
Wow, when did he leave microsoft? (I know some might be asking when he joined lol)
Not all that long ago https://news.ycombinator.com/item?id=46784572
systemd-boot is only similar to systemd in name; it started as another project and was renamed.
It’s been merged into the systemd project, so one must assume that the systemd maintainers have some level of influence over it.
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.
Famous last words. To answer your question: because you will have to deal with the aftermath.
because it “runs for a few seconds” until the maintainers decide it should run for a few minutes, see init for an example
Because they're going to try to use it to make it impossible for you to run an operating system that isn't spyware.
Fortunately your doctor has medication for this.
Now that's rich. Are you indirectly telling us that Arch Linux and NixOS are spyware?
Can you actually definitively prove this, or is this just more fearmongering from the anti-systemd crowd that I at least don't at all take seriously?
What fearmongering has the anti-systemd crowd been selling you? Genuinely curious because I wish I wasn't running systemd. My perspective is that the things they (we?) are saying are basically correct. But the service manager works well enough that most distros have accepted the downsides.
> What fearmongering has the anti-systemd crowd been selling you?
I can't tell if this is a legitimate inquiry or if you are just trolling with this argument.
it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
at some point you people need to stop pretending it’s all just a slippery “slope fallacy” every single time they push for more control
> it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
Can you prove beyond a reasonable doubt that they intend to force this on you without any way of disabling it, or that they have already done so? Because unless they plan to do this (and you have concrete proof of such and not just "well they could do this" claims) or they have already done it across a significant portion of the Linux distribution ecosystem (and no, distros voluntarily switching to systemd is not forcing anyone to do anything), this is fearmongering. Simple as that.
> it is really fearmongering when the systemd people literally founded a company to develop attestation for linux?
Considering it changes nothing on what they actually work on on systemd I would give this a yes. Every time I hear "they will do this or that" it just never really happened. So far it feels more like "the boy who cried wolf" than "slippery slope" to me. But maybe I am missing something?
A lot of the devs have always here and there added features for secure/measured boot and image based OSes and things that make them more usable to daily drive (hermetic /usr/, UKIs, sysext, portable services, mkosi, DDIs, ...). A lot of the things make image based systems more modifiable/user accessible without compromising on the general security aspect.
If they really wanted to lock in Linux users to a single blessed image from them they would have had a better chance when Lennart was working at Microsoft (which generally is the only preinstalled CA) instead of starting a "competing" company (they are targeting a different niche from what I understand).
This, and locking down everyone to a single blessed Linux distro would be... Rather difficult given how widespread Linux is and just how many distros exist. It is one thing for each distro to decide "Hey, let's use systemd". Gnome requires it but that's Gnome; there is nothing stopping you from using XFCE, or I3, or KDE, or... It is a totally different thing to make every Linux distro stop working (and have said distro go along with that) because that distro isn't the "blessed" one. Microsoft can pull this off because they're Microsoft and they have total control over one of the most dominant operating systems. Apple can pull this off because they're Apple and control everything from the hardware upwards. Linux is neither of these. I would go so far as to argue that the BSDs have a better chance of pulling off something like this than Lennart does. RedHat may have a lot of influence in the Linux world, but it certainly doesn't have some secret god mode switch it can flip and universally make every distro conform to it's wants and desires.
Sir, this is a Wendy's
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?
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.
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.
Works just fine for legal ass coverage
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.
I glad that I moved to green pastures... Aka Debian.
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.")
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?
When they started slipping ads into aptitude. I think that's when most of us started giving Canonical the side-eye
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.
Up voted for Devuan. Getting services to work is a hassle but really easy after using the same template for start/stops.
[dead]