On 7/22/22 05:40, Lennart Poettering wrote: > On Mi, 20.07.22 20:48, Demi Marie Obenour (demioben...@gmail.com) wrote: > >>> So, in my view of the world, the kernel command line is fixated in the >>> unified kernel image (if you use systemd-stub, this already happens if >>> a .cmdline PE section exists, and SecureBoot is on). If you want to >>> override it, then turn off SecureBoot. >> This is not a sufficient solution, as it creates an unnecessary >> security risk. I have had more than one occasion where my system was >> unbootable and I had to rescue it, either by using an installation >> image or by editing the kernel command line. Disabling secure >> boot would allow this, but it also means that *any* code might run, >> which is not wanted. What I want is to be able to authenticate as >> an authorized superuser, and know that the only code that will be >> able to run is code that would have run anyway, code involved in >> the recovery mechanism, and code that I have specifically entered or >> caused to be run. There is a huge difference between “anything at >> all can run” and “an authenticated and authorized superuser can >> provide additional code to be run”. > > The thing is: if you want to allow making the kernel command line > controllable by the user but still protect it cryptographically, then > you need to authenticate it before passing control to the kernel. For > example in sd-stub, i.e. the UEFI stub code that runs in UEFI mode, > before ExitBootServices() is called. > > But authenticating that is messy, because you need to authenticate it > against something, i.e. user password (i.e. interactivity at each > boot), or TPM. Both is very messy (because it either takes > non-interactive boot away, or means embeddeding a TPM stack of some > form into sd-stub, because UEFI will only give you access to the TPM > in a bytestream, not with high-level commands). > > Hence, I am not convinved the benefit really outweighs the effort > here. Modifying your kernel command line is invasive, and hackish, and > hence I think it's OK to leave it out of the model.
What I would really like is to boot normally by default, but allow the user to break into a rescue mode by pressing a key at a certain point during boot. After authenticating, the user would be able to select between the last N installed kernels (kernel/hypervisor combos for Xen users) and would also be able to select a rescue mode. One might decide to allow booting the previous kernel without authentication if the most recent (newly installed) kernel has not yet booted successfully. Something similar can be done with grub, but grub is extremely complex and has a slew of vulnerabilities. I would like a simpler and safer solution. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
