Signing systemd-boot EFI binaries under /usr

[mcassaniti]

All files ending with .efi or .EFI under the ESP partition get signed for secure boot if using the secure boot option. This is indeed a good thing. If something like bootctl add is run then the file /usr/lib/systemd/boot/efi/systemd-bootx64.efi can be copied back into the ESP. This copy is unsigned however and will break secure boot.

Note that copying sytemd-boot to the ESP can sometimes happen without an explicit user request, and even if the user explicitly does request it that should not cause secure boot to fail.

My suggestion would be to sign EFI files under /usr/lib/systemd/boot/efi before the contents of root or /usr become read-only. Currently files under the ESP partition are signed after the point where no more changes to root or /usr should occur. I'd like to collect feedback before submitting a PR.

[poettering]

Note that this is not as easy as it sounds. In Verity mode we want to encode the root hash in the kernel command line included in the unified kernel image. And since the Verity root hash covers the /usr tree, you thus cannot embed the kernel in its final form in /usr/, as you have a cycle problem then...

[mcassaniti]

@poettering You are correct about the cyclic problem, but (unless I'm wrong) the file I'm looking to make sure is signed is not the kernel EFI image. It should be the systemd-boot loader that will load such a kernel image.

I'm human and I'm known to be wrong. I figure I've got a 50/50 chance.

[mcassaniti]

@DaanDeMeyer Should I take that as a sign to start on a PR?

[behrmann]

That's just just a label for sorting issues, but just start a PR and then we'll see what comes out. It's always easier to talk about concrete stuff. :)

To topic: If you're only after signing systemd-boot. That sounds pretty self-contained and doesn't have the the cycle problem.

[DaanDeMeyer]

I'm not sure if this is something mkosi should do. If I understand correctly, bootctl should take care of signing the binaries from /usr when bootctl add is executed

[poettering]

@poettering You are correct about the cyclic problem, but (unless I'm wrong) the file I'm looking to make sure is signed is not the kernel EFI image. It should be the systemd-boot loader that will load such a kernel image.

Oh, you are right. Ignore me, signing sd-boot in /usr/ should be OK.

[poettering]

I'm not sure if this is something mkosi should do. If I understand correctly, bootctl should take care of signing the binaries from /usr when bootctl add is executed

Hmm, given sbsign and so on exist already, is bootctl really the right place?

Givning the signing keys for the secureboot stuff area actually maintained by mkosi right now, it probably does make sense that mkosi also signs the sd-boot EFI binary with the same key it would sign the unified kernels with.

[mcassaniti]

I'm not sure if this is something mkosi should do. If I understand correctly, bootctl should take care of signing the binaries from /usr when bootctl add is executed

I'm seeing bootctl update run from systemd-boot-update.service copy systemd-boot which is unsigned. It certainly isn't signed with the keys used by mkosi if signing is enabled, and it would only be the original distribution vendor key if that.

Givning the signing keys for the secureboot stuff area actually maintained by mkosi right now, it probably does make sense that mkosi also signs the sd-boot EFI binary with the same key it would sign the unified kernels with.

Agreed. It seems I'm thinking in the same direction. Here comes yet another PR. One day I'll stop.

[DaanDeMeyer]

I'm seeing bootctl update run from systemd-boot-update.service copy systemd-boot which is unsigned. It certainly isn't signed with the keys used by mkosi if signing is enabled, and it would only be the original distribution vendor key if that.

My comment was worded weirdly, I was wondering whether we should make bootctl do the signing, you're right that it doesn't do so already. I'm not sure it's a good idea to replace the unsigned binaries by the signed ones though. I understand you'd likely want to do that so that bootctl add picks those up automatically, but it feels like the wrong way to go about it.

Hmm, given sbsign and so on exist already, is bootctl really the right place?

Now that systemd-boot has built-in support for enrolling secure boot keys, wouldn't it make sense to support more of the user facing parts of secure boot in bootctl as well?

What about optionally allowing to provide keys to bootctl add that it uses to sign the binaries when installing them? And then have bootctl look for the keys in system credentials as well if not explicitly provided so that bootctl add when executed by systemd-boot-update.service has a way to pick up the keys as well?

[mcassaniti]

OK, that does sound reasonable. What if the built images should not provide any private keys though? It sounds like we need (at least) two options here. I'd like the images I build to not include the private keys used for UEFI signing or need to distribute them with the image.

On top of all of this, what should the default behaviour be?

[behrmann]

Now that systemd-boot has built-in support for enrolling secure boot keys, wouldn't it make sense to support more of the user facing parts of secure boot in bootctl as well?

I'm all for that. Making that as seamless as possible can only help secure boot adoption. :)

Signing sytemd-boot in mkosi, with the keys we already manage, makes sense to me, though, since bootctl install and bootctl update already have the logic of preferring files ending in .efi.signed. So if we provide them, it should just work™.

OK, that does sound reasonable. What if the built images should not provide any private keys though? It sounds like we need (at least) two options here. I'd like the images I build to not include the private keys used for UEFI signing or need to distribute them with the image.

Understandable, but if I remember correctly secure_boot_sign works from the outside and won't copy the keys into the image. It does clobber the unsigned files, though, which I think we should not do in this case, as package managers might not like that.

[mcassaniti]

if I remember correctly secure_boot_sign works from the outside and won't copy the keys into the image. It does clobber the unsigned files, though, which I think we should not do in this case, as package managers might not like that.

I think I can compensate for that.

[DaanDeMeyer]

Ahh, I forgot bootctl prefers files with the ".signed" extension. In that case, we can just generated ".signed" files of the unsigned binaries in mkosi, that makes perfect sense.

[poettering]

I think the idea would be to iterate through /usr/lib/systemd/boot/efi/.efi and -- if a secret signing key has been configured -- sign each file there adding in /usr/lib/systemd/boot/efi/.efi.signed for each. Except maybe if the target file already exists, in which case it probably should take precedence.

[mcassaniti]

Closed via #1109.