-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not sign in-place, always require the "-o" parameter. #228
Comments
I second this. The README currently encourages signing images in-place on the EFI partition and add them to sbctl database¹ which is a high security risk as it could lead to signing arbitrary files. A malicious actor could replace an unused image with a rogue one and patiently wait for the user to trigger I think the best practice would be to always keep the unsigned images in a secure, encrypted, partition, and have sbctl sign the trusted unsigned file into the EFI partition. This way, the signed image could always be trusted. Preventing in-place signing would indeed be preferable for all the reasons you mentioned, but insufficient as it wouldn't prevent signing untrusted files. At very least, sbctl should display a warning when signing a file from an unencrypted partition, and certainly not encourage such practice in the README. |
Changing a 3 year old README is not high up on my priority list of "things I'll work work on soon'ish". So please send patches if you would like to see this changed. Some of these files have their own "move signed file into ESP" semantics with a |
Sorry if I sounded harsh or rude. I am already working on a patch. |
Depending on the hooks that users/distros have set up for generating UKIs and signing EFI images provided by packages, the only thing that might be needed is an option to skip signing EFI images on the ESP when running sign-all, and emitting a warning when images on the ESP are signed in-place. This would likely be a simple-to-implement alternative that avoids breaking existing users, while still giving users that care a way to be secure. |
By the way, this isn't only in the the README, it recommends signing in-place in the manpage too. |
The README.md mentions signing EFI files on the EFI system partition (ESP) in-place:
I think this is bad and should be avoided and discouraged:
Signing in-place might be easier; but in the long run, it just introduces more problems; I think.
The README.md should therefore instead suggest (if BOOTX64.EFI is systemd-bootx64.efi):
Here are some locations on ArchLinux if you are searching for where to find them:
KeyTool.efi
comes from/usr/share/efitools/efi/KeyTool.efi
systemd-bootx64.efi
comes from/usr/lib/systemd/boot/efi/systemd-bootx64.efi
fwupdx64.efi
comes from/usr/lib/fwupd/efi/fwupdx64.efi
linux.efi
usually comes from/boot/vmlinuz-linux
linux-hardened.efi
usually comes from/boot/vmlinuz-linux-hardened
shimx64.efi
comes from/usr/share/shim-signed/shimx64.efi
mmx64.efi
(MokManager) comes from/usr/share/shim-signed/mmx64.efi
The text was updated successfully, but these errors were encountered: