On 7/20/22 16:20, Lennart Poettering wrote: > On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek@xxxxxxxxxxxxxxxxxxxxxx) wrote: > >>> I wonder if Qubes OS could use any of this work. It seems that it >>> would be incredibly useful, at least if it supported systems using >>> the Xen hypervisor. >> >> That's probably going to be useful for Qubes OS too, indeed. >> >> It would be even better, if kernel cmdline could be pre-measured too, as >> many kernel parameters may affect overall system security (like >> disabling iommu). There is currently one major issue with this: finding >> root filesystem. If the "initrd cmdline" could be separate from >> "kernel cmdline", then one could include pre-measured safe kernel >> cmdline (perhaps even hardcoded into kernel binary), while still being >> able to instruct initrd where to look for the root fs. Of course, initrd >> would need to be careful about parsing this piece of information >> (probably having some allowlist of options allowed in this case), but >> that's a huge improvement already. There were few other ideas for this >> problem in this very thread too. > > 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”. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
