Re: Suggestion: Use a unified kernel image by default in the future.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/22/22 05:40, Lennart Poettering wrote:
> 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.

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)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux