On Sun, Aug 29, 2021 at 09:02:38PM -0000, Jacob wrote: > Could we add an option to `update-secureboot-policy` so that it can > generate a key that works for signing modules & kernels ?
This would be a low priority to change, and we would need to take a good deal of care around the user interface and documentation for this because we do not want to be giving users a gun to point at their feet. The only reason to add a key to MOK that can be used for signing kernels is if you're not using an official Ubuntu kernel. I think the documentation for how to generate keys for this belongs with instructions around booting unofficial kernels; and wherever that gets documented, it can just as well lay out the full openssl invocation instead of pointing to update-secureboot-policy. And NOT putting it in update-secureboot-policy makes it less likely that users are going to cargo-cult a one-liner command without context. > As an aside, if an attacker has compromised a system and they generate a > signing key ... they could modify and attempt to enrol a key that allows > kernel signing ... The "attempt to enroll" requires the user to interface with MokManager at the console. It is by design that you cannot non-interactively enroll a MOK from userspace. So this scenario is already accounted for and still prevents an attacker from getting persistent access to the firmware without involvement of someone with control of the local console. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939565 Title: kernel signed by mok failed to boot if secure boot is on To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1939565/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
