What guide? Come on, you can’t just drop that nugget and not link to it. I’m always looking for guides, especially when they’re excellent.
As for the rest, I understand that only grub-*-signed is being stripped down to reduce attack surface and that the plain old unsigned grub which is used without secure boot will just stay the same as it always was. And since the latter implies the good old hw_access(evildoer) == game_over(), it is not considered a security boundary and hence no security support.
It’s a long and tedious process, because you are installing Ubuntu by hand with debootstrap. I always wanted to add support to the installer instead. Then Ubuntu did, and I thought about discontinuing the guide, but I still needed server and multi-disk support.
At this point, I probably will just go straight to updating for 26.04. I need to review the dracut situation too.
Anyway, back on to this issue… From the update, it sounds like MD RAID1 may be staying. If so, that is good.
I’ve been mulling this over and over in my head and couldn’t find a definitive answer. Isn’t this a moot point, because this is explicitly about Secure Boot which is also UEFI only?
Maybe sd-boot is, in fact, the better option, but then Ubuntu would have to support two different boot loaders, one for Secure Boot, i.e. sd-boot, and GRUB2 for everything else. While I am personally leaning more towards sd-boot, because, from what I’ve read, it seems to be the perfect fit, I also cannot dismiss synergy effects from going with GRUB2 for both, Secure Boot being just a special case of the more general and well understood/supported GRUB2 procedure.
Please don’t confuse my questions for me taking a position. I’m deliberately not doing that (yet). First I’m trying to understand what the justification is for this change, and trying not to assume anything in the justification that isn’t stated in this thread.
Sure, and I appreciate your question about actual vulnerabilities. A reference to the actual list of CVEs is important context that is missing from the original post.
That being said, I think the following statement is an opinion:
I don’t think these are relevant CVEs for the motivation presented, though.
And so is the premise of your follow-up question:
If Ubuntu users were, in the default configuration, not vulnerable, then why is it necessary to remove those features from Ubuntu users who wish to opt in to using them? We’re not making the majority of users any safer, and the security team will surely still need to continue to issue security updates for the non-signed case?
I don’t think anyone said that the default configuration isn’t vulnerable or that it doesn’t affect the majority of our users. The list of CVEs I provided are vulnerabilities that I think did affect our users in the past and could have easily been avoided. You also didn’t give me any context for why you think they aren’t relevant.
If you think I’m wrong and those CVEs didn’t actually affect any of our users, that is a valid opinion to hold, but I also think that you have to provide proof.
My base assumption is that a critical CVE in a piece of software we ship does affect us until proven otherwise. The fact that the security team decided to track it in USN and fix it seems to be a good indicator they came to the same conclusion (as we see from @sarnold’s reply above they will reject CVEs that don’t affect us).
I think both @peterwhite23 and I provided good examples for why dismissing the CVEs just because they rely on features that aren’t part of the default configuration is not enough.
So as it stands I think that those last two questions are redundant and also heavily biased because it is not what anyone proposed. The idea is to remove code with vulnerabilities that DO affect the majority of users while benefiting very few (those that debootrap their own installation with custom file systems and FDE setups while still relying on secure boot).
I disagree with removing ZFS, Btrfs, etc with Secure Boot. FreeBSD has Secure Boot, FDE and ZFS and OpenSUSE has Secure Boot, FDE and Btrfs without security problems. These file systems are not the source of security probems and Secure Boot is a requirement for most of us. Such a change would mark a profound exit of most of the developers.
For the record, I am using Secure Boot (SB), “FDE” (everything, except /boot{,/efi}), LVM and BTRFS. This won’t change. Everything required for more sophisticated filesystems etc. belongs in the initrd, so there is no need to worry. That way GRUB2 can be dumbed down to the bare minimum. And as I said, I think even ext4 is overkill, ext2 would suffice or even vFAT, given that SB needs the ESP anyway.
For all I care, in the SB case, there doesn’t need to be a separate /boot partition beside /boot/efi. The latter may be too small by default though, so there should be a way to expand it on install. I am pretty sure there’s some way of calling GParted in the installer for that. But, since I am not in the habit of constantly (re-)installing, I haven’t seen a live installer in a long time.
but that’s exactly the thing, grub can’t be dropped— ubuntu would need to support an additional bootloader which means a higher maintenance burden and bigger testing matrix. so this is why ubuntu won’t switch to systemd-boot……(is it really a switch if boot are in use?) users can switch their own machine tho like popos did
Yes, but you made it about non-UEFI platforms which are irrelevant for SB. I also said, that I cannot dismiss the synergy effects of staying with GRUB2.
But maybe sd-boot is simpler in the long run, I don’t know. It seems to be designed with dumb simplicity and SB mind. It doesn’t need extra care to be made secure, because it’s as minimal as it gets, AFAICT. For instance, as I read between @juliank’s lines (“[initrd] is part of a UKI for now”), it seems to be kind of hard to put GRUB2 in a harness to be extra sure that it cannot take any code paths that undermine Secure Boot.
Also, I wouldn’t want to stray from the official boot loader line, out of fear that there may be surprises on some release-upgrade. I tend to forget such things. Also, sd-boot and initrd extensions would required official vendor signatures, unless one wants to run the mokutil on every kernel upgrade.
I am not arguing against GRUB2, BTW. I am merely suggesting that there may be another way, that hasn’t been explored yet. I’ll take things as they come.
i’m saying it’s a matter of supporting both UEFI and non-UEFI systems, unless systemd-boot gains support for more platforms, it is not a viable option.
‘non-UEFI’ is a well chosen term as it implies there’s more than just BIOS and UEFI to support as mentioned elsewhere in the thread; BIOS may be on the way out, but the others are not..,
And I am simply stating that non-UEFI is irrelevant for the SB case, which this thread is about. And I am well aware of the implications, as I’ve stated multiple times already.
There are already two types of GRUB2 packages, and the signed ones are UEFI-only, for all intents and purposes, since they only make sense in a SB setting. Plus, by the looks of it, there is enough hassle involved with grub-*-signed to at least warrant a look at alternatives, IMHO. Maybe it turns out that sd-boot is so simple that the win outweighs the synergies between signed and unsigned GRUB2? That’s the question, I wanted to raise, nothing more.
In plain English: is it maybe worth dropping grub-*-signed in favor of sd-boot?
based the fact that these systemd-boot and grub are two different code bases; signing a package doesn’t change its code— the last I’ll say about it cause i feel like we might be too noisy on a thread about streamlining around a suggestion that is quite the opposite of streamlining
But dumbing one down (grub signed) does. BTW, all packages are signed, secure apt and all. The signatures we are talking about are for authenticating the boot loader binary at boot.
It is not, but maybe not immediately obvious. My suggestion is about streamlining the effort that goes into supporting SB. As it stands there will (continue to) be two diverging grub tracks. If that effort is greater than just having grub unsigned for non-SB, as it always has been and will be, and sd-boot for SB, it may not be worth it.
P.S.: One last note, the topic title is “Streamlining secure boot”. GRUB2 is only one option and was kind of implied, because Debian and hence Ubuntu have a long history with GRUB, which is precisely why I want to widen the scope, so nobody suffers from tunnel vision.
This seems like the opposite of what I was hoping for, and many others!
For years we’ve waited for the GRUB project to catch up… and finally in version 2.14 (now in 26.04 LTS now) we get support for standard LUKS2 with argon2id and argon2i encryption (that you’d find is used by default when using cryptsetup format without any extra arguments).
Just this week I tested that if you debootstrap a 26.04 system today… then as long as you use grub-efi-amd64-unsigned… it’ll work just great with everything (including /boot) being inside one LUKS2 encrypted root ext4 filesystem (no LVM needed)… the only need for another partition is the EFI system partition (ESP). You can even do a swap file inside the encrypted root filesystem!
But if you install grub-efi-amd64-signed instead (that can get pulled in via recommends which can be confusing) then ‘grub-install’ alone (no other arguments) will default to using signed instead of unsigned.
Which means you will get a GRUB rescue prompt and nothing more… and apparently this is because the signed version of GRUB is missing the argon2i and argon2id modules needed … but unsigned includes them!
So we should be adding support for this to GRUB signed… not taking stuff out of it! Please!
Removing all the stuff proposed means we’re all stuck with unencrypted /boot partitions… where we have to try and forever judge how big they they should be, for future kernels and such. Not to mention that any /boot volume won’t be managed the same as the rest (e.g. snapshots if doing something like btrfs). It also means any bad actor can fiddle with grub config (e.g. grub.cfg) in that unencrypted volume too!
No, that’s what UKI’s are for. They may be able to fiddle, but they won’t get very far, because they can’t coerce GRUB2 into opening an initrd that’s not the sealed one. Encryption of /boot was never a sufficient security measure, see the comments above about that.
If the decision is made to go ahead then LVM migration of /boot should be fully supported via an automated script to reduce the LVM size and add the necessary partition rather than expecting users (who may not be competent to do this) . This should include GPT and MBR formatted drives as its not possible to assume older hardware BIOSes can support UEFI boot and GPT. Maybe that should be a separate step.
The same is true of many of the other aspects that might get stripped out of grub. As far as I can tell many could be handled automatically via an upgrade script.
I don’t see a need for using a UKI… GRUB 2 has served me just fine for years… and I find it more versatile to use when there are issues.
TPM FDE isn’t available on all systems and has been known to have its own set of flaws… so it’s no replacement for just doing this in software (i.e. pure LUKS 2) which can be much more easily updated and upgraded.
Therefore (at least to me) the F in FDE for FULL disk encryption means every filesystem except for the ESP (EFI system partition). We shouldn’t care that the ESP isn’t as the only stuff that’s meant to be on there are signed binaries which Secure Boot takes care of checking for us.
Also no, stuff in /boot/grub/ can be altered if the /boot filesystem is left unencrypted. Just because signed grub can’t execute something which isn’t also signed… doesn’t mean people can’t mess around with other interpreted bits of GRUB left in /boot/grub/ such as config (potentially making the system unbootable) or alter images/themes and other things.
The op talks of security risks using images (e.g. jpeg/png)… but I don’t see what that risk is, especially if it’s on an encrypted filesystem?
The op also talks of security risks with ‘a lot of parsers for file systems and other things’… could you please detail what they are? Or perhaps just consider removing the troublesome ones only?
Ultimately this just seems like a very heavy handed way to go.
GRUB is already a grand (get it?) and trusted boot loader which already works… it just needs re-signing to include argon2 support now that it is finally here.
