Then simply don’t use the signed grub package. It’s as easy as disabling secure boot in the UEFI.
Have you even read the proposal? It’s precisely those considerations that prompted this. If GRUB2 can’t even do such things, because the code isn’t there, then it’s impossible to coerce it to do anything outside the intended use. An unbootable system may be the worst that can still happen, but for that an evil maid could simply damage the device, so no win to them and no loss to us.
Am I the only person who has noticed that? There are plans and intentions that we are ignorant of. Sometimes plans get changed and even dropped. Sometimes they get carried through to a conclusion.
Remember LiLo anyone? Linux Loader. That was what was used before Grub. Why should there not be something after Grub?
But it can! That’s what I’m saying, it can now finally understand LUKS2 with argon2 encryption (the default when using ‘cryptsetup format’)… version 2.14 is in 26.04 LTS right now, it’s just that the signed version needs resigning with that module included!
Ultimately it boils down to whether you (or anyone reading this) thinks…
a) The “line” should be drawn where your UEFI or non-UEFI based bootloader is mostly a static thing where it reads any customisation/options/config via another filesystem which stores that stuff (which may or may not be encrypted)… and when it comes to booting a Linux kernel (or anything else like memtest) it should read that off another (or same) filesystem also (again possibly encrypted).
b) The “line” should be drawn where your UEFI or non-UEFI based bootloader is again a mostly static thing but has little (if any) need to read any customisation files (e.g. jpg/png images) from other filesystems, but it would still need to read its config/options from another filesystem anyway (which again may or may not be encrypted)… but also still needs to find the Linux kernel on another filesystem (also possibly encrypted) and boot it.
c) The “line” should be that if you have UEFI then essentially don’t bother with a real bootloader at all… just boots the kernel as directly as possible by using a UKI. Then if you’re non-UEFI then err… you use GRUB anyway or maybe load the UKI using Limine!? Either way it’s not as consistent between non-UEFI and UEFI.
Ultimately I think anyone who says “just turn off Secure Boot” isn’t really acting in good faith in this discussion… the whole point is to keep this turned on (as it is turned on for the vast majority of new hardware… and asking new users to fiddle with that is just counterintuitive).
As a distribution… Ubuntu has by default always been option a) since it’s inception with GRUB. But there has never been anything to stop people from reworking this into any alternative they like (like another bootloader or a UKI) which I’m all in favour of… until Secure Boot came along and limited the choices that is!
It sounds like the op prefers option b)… but unless they say which modules were causing a problem, it just seems heavy handed… and doesn’t really change that GRUB needs to access other filesystems anyway! Is there some kind of security bug involving GRUB reading a JPEG or something?
Like it or not… I am in the “camp” that says I prefer my GRUB bootloader to be… a) slim enough to work and be customisable… b) read as much customisation/config data from another filesystem (even if encrypted) to keep what is in the ESP or MBR at a minimum… c) be able to boot kernels from another/same filesystem (again even if encrypted).
But that’s essentially the status quo as it is now… it’s just that signed GRUB needs to be signed with whatever unsigned GRUB has… and if unsigned GRUB has stuff in it which is problematic (from a security perspective), then tell us what those issues are and it’ll make sense to remove them.
I believe signed GRUB can already read from encrypted filesystems now (just not LUKS 2 and argon2)… so it’s not like it can’t do this in some respects already. This feels like it’ll be a massive downgrade… and basically a precursor to getting people off GRUB.
Sorry, that wasn’t at all the context of that. Read my message again. You were talking about ways an evil maid could do evil things by exploiting GRUB2’s extra code, which is precisely why the streamlining.
You are also mixing up UEFI and Secure Boot. You can keep using grub-efi* (the unsigned ones). They won’t be touched. This is purely about reducing attack surface, so evil maid can’t exploit grub in ways described by you, among others. You are essentially saying that there are plenty ways around Secure Boot with GRUB2 (signed) is right now, while simultaneously claiming nothing can be done about it. Well, you’re wrong. Also, encrypting /boot is not a security measure, because said evil maid could just exploit said extra code in GRUB2 to install a Trojan Horse to grab your encryption key.
If you are not worried about evil maids, e.g. when using a stationary PC or server which is secure from tampering by random strangers, then Secure Boot is pointless and you can just disable it.
But there may be other Ubuntu users who actually need SB to work as intended. If you had read the whole thread, of which I am rather doubtful, you should have found that I’ve even suggested looking into systemd-boot, because it looks like a better fit for SB, like sd-boot for UEFI+SB and grub for plain UEFI, BIOS etc.
I’m sorry but I don’t think you understand what I am saying at all.
I am not mixing anything up and I know the difference between UEFI and Secure Boot.
If everything except for the ESP was on a single encrypted filesystem (lets say ext4 with LUKS2/argon2 encryption in this example)… and by everything I mean the root filesystem and /boot… then you’d be able to continue to use all the current functionality of GRUB when using 2.14 unsigned and signed (if someone would just resign it) plus a single UEFI binary would exist on ESP that would (instead of encryption) be protected by Secure Boot so tampering wouldn’t be an issue.
That should be the goal here.
People like and have used GRUB for years. I’m all for letting people choose an alternative way to boot their systems… and to be honest I’m not fussed if GRUB gets installed from a regular Ubuntu ISO install (as I use debootstrap anyway, the normal Ubuntu installation process is dreadful in my opinion)… but to limit the signed version of GRUB to not match what the unsigned can do… is taking the decision out of users hands.
So taking more modules out of GRUB (signed or unsigned) is simply and arbitrarily limiting the usefulness of GRUB to those who want to continue to use it (when my opinion they should have parity with each other, and so signed can boot into LUKS2/argon2 encrypted filesystems). I’ll take back the ‘arbitrarily’ if the op can actually state what security issues in what modules they’re trying to mitigate by their removal.
No, it should decidedly not. And I did understand correctly. But you fail to understand the proposal. You can’t access boot without jumping through some burning hoops to decrypt it, first. And GRUB has been burnt multiple times already. There is no point in signing buggy code, because Secure Boot doesn’t measure what that code is doing, it just reassures you that it is as delivered by the signing party, i.e. Ubuntu. The best one can do is to minimize the code that’s actually required for bootstrapping. Plus, with the initrd being on encrypted /boot there is no way of validating it before /boot is mounted, so the sealing wouldn’t work, hence the UKI approach, which has everything in one blob; flip one bit in that and Secure Boot will not validate it. The only thing left to exploit is GRUB then, so best make sure it’s rock solid, by ripping out code that was never supported.
But the more I write about this, the more I’m realizing that boot loaders aren’t required at all with UEFI, for UEFI itself is the boot loader, so GRUB loading a UKI is kind of pointless, just have UEFI load it.
@juliank, maybe this article on LWN which links to this one can help illustrate what I mean. Having watched Lewandowska’s talk, I’ll say nmbl (no more bootloader) should be the approach for true Secure Boot. BTW, Marta Lewandowska is named as GRUB maintainer in that article, which should tell you everything you need to know. 
Just trying to understand …
Your proposal is related to changes on the basis of exposures while under the protection of Secure Boot. Correct?
Under that paradigm, Bitlocker, or equivalent, prevents non-authorized access do all things related to disks or on them.
That being the case, why is GRUB and “weak link” … if it is already protected by the “golden dome” of Secure Boot ?
As for exposures when Secure Boot is disabled, haven’t the risks already been weighed and deemed acceptable by those operating in that disabled mode ?
As I said, just trying to understand why what could be a very disruptive initiative (as the comments already posted seem to imply) is being entertained … at all!
Secure Boot is no remedy for software bugs. If the signed boot loader, e.g. grub, is easily exploitable, then SB will happily run it, for it passed validation. And, IIRC, it was a major undertaking to revoke and replace the key(s) used to sign that vulnerable package. Also, look at what caused it: images, as in picutures, IP, HTTP etc. I think, that particular USN was unavoidable, since there were issues in the shim and some basic GRUB code as well, but you should be able to grasp the bigger picture; less code is (almost) always more secure.
While I don’t advise it, it is technically possible with GRUB 2.14 to have a built-in, hardcoded grub.cfg for secure boot EFI grub now the BLS support is upstream. Then you can have a small loader configuration in the ESP and the BLS snippets that define the rest of the configuration in /boot and you’re good to go.
In and of itself, reducing code does not reduce exposure to risk.
Maybe I am wrong, but it seems to me that we are overlooking the role of the Administrator in performing
Or, again, I am missing something!
Yes, you are.
I hope there will be a compromise solution to give the choice to the user in the Ubuntu installer GRUB or Systemd-boot.
This will solve the following issues:
We have no plans to use systemd-boot, it does not address the requirements of a general purpose distribution - we need to boot on BIOS, UEFI, OpenFirmware, amongst other things, and we don’t want to maintain different boot stacks for different systems.
Keep in mind that systemd-boot also lacks even more features, like RAID-1 or ext4 support which are integral to our boot strategy.
But proper Secure Boot might deserve its exception, for it is not general purpose either, pretty much being married to UEFI.
But isn’t that what the initrd is for, ultimately? AFAIK, initramfs-tools has MODLUES=most as the default, a standard installation already puts the most common filesystem and all the block devices drivers inside the initrd. Just use that approach for the sealed initrd and you’re off to the races. Lennart Poettering also wrote something about extensible initrds, but I haven’t found anything beyond his initial proposal on that:
That’s essentially the UKI idea, which has already been realized and is currently utilized by the snapped TPM-backed FDE mentioned above, IIUC. Just put “most” modules and stuff like cryptsetup on the initrd which is sealed within said UKI. Plus, there really is no need for /boot anymore, because everything necessary is, or can be made to be, in the UKI on the ESP.
As far as I can tell, GRUB, or any fancy boot loader for that matter, is utterly redundant with UEFI boot, hence my suggestion to look into “nmbl”, which is spearheaded by GRUB’s own maintainer, no less; put a UKI on the ESP and wire it up to the UEFI boot menu. Get the kernel up and running at the earliest stage possible and let it and companion tools on the sealed initrd handle the rest. Maybe something like initrd “hopping” could become a thing: most basic initrd in the UKI, which includes validation tools to pull in the initrd created by initramfs-tools, or dracut or whatever, which gets signed with the MOK as last step of update-initramfs. E.g. mount the initrds as an overlayfs of all “lowerdirs”, or similar.
I am only saying this, because it seems non-trivial to do the GRUB-stripping, so it isn’t free. Also, by being part of Secure Boot, GRUB has become a (partial) security boundary, and someone from the Security Team has already all but said, that there’d have to be two different GRUB tracks. So, maybe, just maybe, all the effort needed to streamline GRUB is more than finding a simple and workable solution for the special case that is Secure Boot.
But that would just be icing on the cake, I reckon. If such extension initrds existed, they would save the MOK signing step mentioned above. Also, no more local dracut or initramfs, for Secure Boot at least.