On Mi, 20.07.22 20:48, Demi Marie Obenour (demiobenour@xxxxxxxxx) 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. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
