Discussion about secure boot for 26.10

Lounge
1

To be honest, your reasoning does not entirely convince me.

You’re right: encrypted /boot alone does not provide actual security without additional measurements. But hey, I am pretty much aware of this. And I am pretty much sure that most people who have managed to install ubuntu with encrypted /boot are also aware of this because they need to deliberately disable “Secure Boot” for this.

This is why (on critical systems) I have installed a cron job taking sha512sum’s of all the unencrypted contents of the disk. Those are then stored within the encrypted root. Before booting the system, I boot some live-ISO, unlock the root-fs and verify that those contents have not been modified. Not perfect and cumbesome, I know.

On the other hand: how many (arbitrary) ubuntu-users are aware of the fact that their trusted (because signed+SecureBooted) kernel will happily execute every malicious code that the unprotected+unencrypted initrd is waiting to receive? I have had this debate multiple times already. None of the people I talked about this topic was aware of this problem. They all were pretty convinced that the are safe because they enabled “Secure Boot”. And one of them was actually a “Release Manager” of a big company who is also responsible for security of their products. Now THAT smells like Snake Oil to me!

You really think an attacker will wait for vulnerabilities in filesystem/imaging/partitioning code when unencrypted initrd can be tampered so easily? Don’t you think an attacker would take the easiest route?

Please reconsider the ordering of your actions! Please do NOT remove (imperfect) measures (e.g. luks support in grub) before the “Secure Boot” path is REALLY secure in every aspect.

2

You should give Ubuntu Desktop 26.04 with TPM-backed FDE — yes, with an unencrypted /boot — a spin. You will find that there is no unmeasured code execution possible — the initrd is in a sealed UKI —, to the point of actual pain, even; see the most recent observations by @paddylandau and yours truly in Support and Help. If the measurements are off, the TPM won’t release the master key, so you’ll be asked for the recovery key. The latter happening without prior warning by some update routine should give the user pause. Even the boot order is sealed.

If anything, they have overdone it with sealing the actual kernel command line, because I’m having a hard time finding ways to circumvent SB that way, but I’m willing to accept that I haven’t looked/tried hard enough; better safe than sorry.

They haven’t. :wink:

1 Like
3

So I’ll give it a try. Any pointers to informations how this is to be done with subiquity-based autoinstall using cloud-init user-data?

Uh? Does that mean there’s no way to install multiple OSes onto one machine and have a boot menu which of them to boot?

I’d hope it is still possible to customize from /etc/default/grub or something?

And what do you do if your HW needs some special settings to get a stable kernel?

Still not convinced on that. My customized autoinstall setup, which worked flawlessly in 24.04, fails miserably with 26.04. Fails to unlock root-fs and throws me into initrd-prompt.

4

Sorry, no. Haven’t come around to doing anything real with autoinstall, but I’d guess there shouldn’t be anything special to TPM/FDE.

No, I don’t think that’s what that means, as long as the boot order is fixed. Since I’m doing my experiments in a VM, I usually install from a SATA DVD-ROM device, which I then simply disable in the boot list. Forgetting to do so and then selecting boot from next device in the grub menu of the live installer will cause the recovery key prompt.

Not quite.

That has got to be an edge case, like in that topic; I still believe there should be ways to deal with such cases by proper EFI settings. Most anything else doesn’t need to be set this early and can be dealt with by sysctl and sysfs settings and their companion boot services, systemd-sysctl.service and sysfsutils.service.

How about you try walking before running autoinstall; might well be some setting of yours.

I am very much convinced, from my own experience that TPM/FDE does what it is designed to do. And the point still is that one does not need a boot loader that is its own OS, essentially. Back in the days of GRUB legacy /boot on a separate ext2 was the way to go and nobody ever complained about it, because it’s just the right way to do it. Then GRUB2 came along, with its feature creep. And now we are trying to make GRUB2 more like GRUB1 again.

Look at why UEFI requires a FAT32 ESP, if you need any more convincing that boot loaders need to be as stupid as remotely possible.

5

Just tried:

  1. enabled secure boot
  2. installed a minimal system with crypted root and uncrypted /boot
  3. apt update/full-upgrade
  4. had to manually run update-grub, since new kernel (7-0.0.28-generic) was installed, but for some reason grub.cfg was not updated properly.
  5. reboot, to get new kernel live
  6. executed “cat /etc/hosts >>/boot/initrd.img-7.0.0.28-generic”
  7. reboot. SUCCEEDS without any warning that initrd has been modified
  8. checked with mokutil that secure boot is actually active.

So no: I am still not convinced!

With 24.04, I actually have crypted /boot with secure-boot enabled. This, I can not get working on 26.04.

And yes: 26.04 still smells like Snake Oil to me.

6

Did you actually enable TPM-backed FDE? Secure Boot alone isn’t enough for all the bells and whistles. BTW, there is no /boot/initrd* with TPM-backed FDE, because, as mentioned above, it’s all in a UKI.

7

This entire discussion was moved to the Lounge where you can continue the talking points to your heart’s content.

Thanks

8

I don’t think the server images have the full support for the new TPM based FDE yet… AFAIK only the desktop installer has that integration up to now…

Since it has originally been designed for UbuntuCore which is for appliances, robotics, industrial, medical and IoT devices, it was not designed for multiple OSes (you rarely find dual boot in your automotive in-car computer :slightly_smiling_face:), this might come later though…

9

I’ve been experimenting extensively with:

Version 1. Ubuntu Desktop 26.04 — TPM-backed with FDE
Version 2. Ubuntu Core 26 — TPM-backed with FDE
Version 3. Ubuntu Server 26.04 — TPM-backed isn’t yet available

So, I can provide some comments and answers. These apply to versions 1 and 2 above, because version 3 still works like the old 24.04, albeit there is a way to simulate (imperfectly!) version 2.

Thus, my comments do not apply to systems without TPM-backed FDE.

The boot order is controlled via the BIOS only, because the only system that GRUB will boot is the only one available, i.e. version 1 or 2.

I absolutely concur. This is, alas, a deal-breaker for me on my server machine. Unless fixed, I have to use version 3 from above, which is terribly frustrating. I hope that this is solved before the .1 release in August.

Alas, this is a serious problem, as I noted above. Two bug reports are relevant here:

If these affect you, please vote for them.

My particular one probably is, but there is a surprising number of people who need this for display problems. They won’t be able to use version 1.

I think that point 2 is where you deviated, because point 4 would have borked your system (as noted above). To test what Peter has been talking about, you need to install either Ubuntu Desktop 26.04 or Ubuntu Core 26 with TPM-backed FDE. (Without TPM-backed FDE, they’re still like 24.04 in how they work.) FDE wipes your entire drive, so you cannot dual-boot. If you need to dual-boot, you cannot use Ubuntu’s TPM-backed FDE.

If you use TPM-backed FDE, you will discover that Ubuntu Desktop 26.04 and Ubuntu Core 26 really are clamped down. The only way to access your data without using the proper boot method is to use a Live USB, and knowing your LUKS passphrase. As the LUKS passphrase isn’t given to you on installation, you also need to know how to get your LUKS passphrase from your system’s recovery key.

If you use the Live USB to successfully and maliciously amend GRUB or /boot, and then try to reboot, the TPM chip rejects the attempt, and you have to use the recovery key, which would be a clue that something is afoot. The same if you disable Secure Boot.

Of course, if a bad actor had physical access to your machine, all bets are off anyway because of the Evil Maid attack — a physical keylogger could be installed.

Give this a bash and let us know how you get on. If you really can easily fool the system, I would be keen on knowing the exact steps that you took; it would be a security vulnerability that would be worth reporting.

10

This is a slippery slope since there needs to be some mitigation of the allowed cmdline args you should be able to modify (while others might allow you to break out of the trusted boot path), that needs proper design and implementation which I doubt can happen in time for the .1 release.

The existing implementation has also been pen-tested and certified by several entities where needed for industrial grade security (since it is shared with (or rather originating from) UbuntuCore), if you change such a thing that likely also needs re-certification which will not go fast either …

11

Thank you for the response, Oliver.

This means that I cannot use Ubuntu Core 26 for my server, which I find terribly disappointing.

Surely the whole point of system.kernel.dangerous-cmdline-append is to be able to attend to unusual (or, in the case of certain display problems, not so unusual) cases?

I recall when a regression caused my display to stop working correctly. This affected multiple people. Then, a second regression not much later caused a problem for many people (including me) with certain Intel hardware.

For the few months that it took for Canonical to fix these, all affected users had to use one or both of acpi_backlight and intel_iommu. These can’t be added in the new system!

Imagine that this happens again. All affected users with TPM-backed FDE 26.04 would have to reinstall the entire system, with lowered security, to be able to use their computer again! It wouldn’t be a good look for Canonical.

This is discouraging. I was so excited about Ubuntu 26.04 and Core 26, but this has put quite a damper on it.

12

Yes, it is exactly for this … but with the focus on Core it also means it is for the owners of a private store that build their images from scratch … that means they have their own gadget snap uploaded to their private store where they can use that parameter baked into the gadget, in that context the option works very well …

In public images where the enduser does not own the gadget you simply can not change the parameter at all …

Note though, I just side-stepped into an additional role at Canonical called the “Supporting Ubuntu Core Product Manager”, one big focus of that role is to bring Ubuntu Core to the community…

In that role I plan to start regular public Ubuntu Core Office Hours (video calls once a month or so) where we can discuss exactly such issues and bring forward the Core adoption in the community …

We’re also working on a new concept for gadget snaps that will enable you to upload your own gadget to the global store eventually (without the need for a paid private store), with that you then can very simple build your own server images adjusted for your hardware (even with all the apps you want pre-seeded/pre-configured for your use-case ) :slight_smile:

So stay tuned, I’ll likely announce something after Canonical’s summer break (i.e. end of August)

(also, to whet your appetite, gadget editing, image building and such for Core will get shiny new GUI tools soon that will make all this stuff easier without needing a degree in UbuntuCore … here is an initial preview of what I mean: GitHub - ogra1/ubuntu-core-model-builder · GitHub )

2 Likes
13

That’s fabulous, Oliver!

Creating gadget snaps, and looking at your GUI, I confess that I’m feeling overwhelmed. I’m not all that technical, but it looks like it might help.

The only two things that are stopping me from using Ubuntu Core 26 are this problem with GRUB, and the inability to use fwupd. Everything else that I’ve tested works perfectly. If the gadget snaps solve these two problems, I’m all for it!

Thank you for all the time and patience that you’ve had with my interminable questions!

1 Like
14

Unfortunately it does not.

I could have crypted /boot on 24.04. With 26.04, I am struggling for more than two weeks to get this working. Still no go.

To sum up:

  1. not supported for server installs
  2. No way to dual-boot
  3. No way to fix HW problems on kernel command line
  4. wipes entire drive, no way to have customized partitioning
  5. if you boot your system with the recovery key once, you can’t remove or replace the passphrase or PIN anymore. On subsequent boots, you have to continue using your recovery key.
  6. Disk re-encryption not supported.
  7. no information available how to set up autoinstalls

All this are serious limitations. For me, those are show-stoppers.

Anyway, they urge ahead and remove luks from grub, so that the setup that worked on 24.04 does not work any more.

Given this, 26.04 is not usable for me…

15

The gadget can only solve one of them, I think the fwupd snap has not been designed with usage on systems that have no polkit in mind … this would have to be fixed in the app’s snap (simply allow to run it as root) …

16

You are aware that these removal plans are for 26.10 onwards ? Current grub should still have LUKS …

17

Removal might be PLANNED for 26.10. But it already does NOT WORK on 26.04 anymore.

1 Like
18

I’ve already tried this, both with and without root, and I get error messages. We’ve discussed it in another thread.

1 Like
19

Yes I’m aware… there is something inside the tool itself or in a wrapper from the snap packaging that hard-wires polkit no matter how you run it, this was what I was referring to.

20

So downloaded 26.04-desktop and tried: it complains that TPM is no usable because another OS has already stored a key. Factory-reset does not help, gives the same error:

IMG_3922
IMG_39221920×1440 633 KB

Also tried the suggestions which are shown under “Learn more about hardware backed encryption”. Does not solve the problem.