On 7/22/22 05:40, Lennart Poettering wrote:
On Mi, 20.07.22 20:48, Demi Marie Obenour (demiobenour(a)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)