Feature request: warn about writing UKIs to the EFI partition on FDE setups

[Syndace]

This might be a bit of a far-fetched feature request, especially given that the UKI support is considered secondary to this tool, but I'd still like to put it out there and hear your thoughts ^^

When generating a UKI, it might be tempting to put it on the EFI partition, next to the other EFI executables (this is also done in the README example). Doing that, however, can be a major security issue on setups with FDE and encrypted /boot (such as Manjaro by default):

Setups with encrypted /boot usually include a copy of an FDE key in the initramfs, otherwise you'd have to type in your FDE password twice during boot (once for the bootloader to decrypt /boot and once for the kernel to decrypt the drive). The initramfs can safely contain a plain copy of the FDE key since it itself resides on the encrypted /boot. When generating a UKI, the initramfs is bundled, including the plain FDE key. Thus, placing the UKI on the EFI partition effectively means copying an unprotected key for your full-disk-encryption to an unencrypted partition, compromising the whole FDE setup.

My suggestion: on setups with encrypted /boot, warn about writing UKIs to the EFI partition (and maybe suggest putting them under /boot next to the initramfs and vmlinuz files etc. instead).

[Foxboron]

This is a secure boot tool, encrypting /boot is completely meaningless in the context of this. This isn't going to be implemented and even figuring out you have setups like "encrypted /boot" is just hard and doesn't provide any value.

[Syndace]

This is a secure boot tool, encrypting /boot is completely meaningless in the context of this.

Huh? Simply running sbctl bundle [...] /boot/efi/EFI/foo.efi completely compromises encryption on vanilla, unmodified installs of some common distros, how is that completely meaningless? This is like GPG warning when permissions are too lenient on the private key file - technically not its job but certainly nice of it to warn users about common pitfalls.

even figuring out you have setups like "encrypted /boot " is just hard

I mean, even a very rough detection logic like

mount | grep luks && echo "be careful"

would be a start to not annoy users without encryption and warn all those that use luks in some way. But sure, saying "too complicated, write docs" is fine too.

doesn't provide any value

I'm not sure how you can say that. This is a pitfall that I believe is very easy to fall into and needs nieche detail knowledge to learn about. I'm sure there are a bunch of setups out there that unknowingly compromise their FDE by having a UKI on the EFI partition.

[Foxboron]

Huh? Simply running sbctl bundle [...] /boot/efi/EFI/foo.efi completely compromises encryption on vanilla, unmodified installs of some common distros, how is that completely meaningless?

Ok, which distros? They should not be doing that as it's extremely poor practice. I fail to believe it applies to "some common distros", beyond misguided decisions from Manjaro.

This is like GPG warning when permissions are too lenient on the private key file - technically not its job but certainly nice of it to warn users about common pitfalls.

You are asking sbctl to care about the environment beyond it's control. This is not the same as checking the file permission of a file they are consuming.

I mean, even a very rough detection logic like

No. This doesn't provide any value and would be meaningless on most installs.

I'm not sure how you can say that. This is a pitfall that I believe is very easy to fall into and needs nieche detail knowledge to learn about. I'm sure there are a bunch of setups out there that unknowingly compromise their FDE by having a UKI on the EFI partition.

No, this is a system installation thing for a couple of poorly thought out distro setups and maybe an installer (or a bad instruction on some wiki). This isn't a common issue

[Foxboron]

and again, encrypting /boot when utilizing Secure Boot is meaningless. The "enter your password twice" problem should not exist in this context.

[Syndace]

Ok, which distros? They should not be doing that as it's extremely poor practice. I fail to believe it applies to "some common distros", beyond misguided decisions from Manjaro.

This is not a question of distro, poor practice or "misguided decisions". AFAIK there is no standard for passing encryption passwords between boot stages, so the only way to avoid double password is to include a key in the initramfs (or have the key on some external medium). Setups that are affected include for example every setup following the Arch wiki: https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Unlocking_the_root_partition_at_boot
Every setup that encrypts /boot is probably affected.

You are asking sbctl to care about the environment beyond it's control. This is not the same as checking the file permission of a file they are consuming.

sbctl is the actor copying the initramfs, including potentially sensitive data, to a new location. I ask sbctl to make sure the target location is appropriate. I don't think that's significantly more indirect or out of control than the GPG example.

No, this is a system installation thing for a couple of poorly thought out distro setups and maybe an installer (or a bad instruction on some wiki).

I agree that embedding the key in the initramfs is ugly and I wish there was a better way, but I don't think there is, so I don't see how this is a distro or wiki issue.

encrypting /boot when utilizing Secure Boot is meaningless. The "enter your password twice" problem should not exist in this context.

This is true, but what do you expect? Just because I have secure boot set up now, should I go out of my way to remove the encryption on my /boot?

[Syndace]

Also from a quick search: at least EndeavourOS and openSUSE also encrypt /boot and copy a key file to the initramfs by default.

[Syndace]

This discussion has been inspiring :) I have removed the keyfile from my initramfs and now boot the UKI directly without taking the extra step via some bootloader. This feels great and is probably the cleanest boot setup I've ever had ^^ Thank you again for this tool.

I still think this is a pitfall that should be warned about in the context of UKIs. But maybe this is more of a documentation task than detection after all. What do you think about a warning in the UKI section of the README that says something like

Warning: some full-disk-encryption setups include a keyfile in the initramfs as outlined in the Arch wiki. Please be aware of that when using the bundle feature.