Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

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

 



On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi <bluca@xxxxxxxxxx> wrote:
>
> > On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
> > <mzerqung(a)0pointer.de&gt; wrote:
> >
> > Basically, I'm saying that the model of trust is flawed because users
> > are unable to work with it.
> >
> > And besides, each level up is a smaller scope from the previous. A
> > cert trusted by shim can execute anything the firmware trusts, a cert
> > trusted by grub can only execute things it trusts, and finally a cert
> > trusted by the OS can only execute things in its context. Once we
> > reach the OS-level, we don't need pre-boot trust anymore. So enrolling
> > certificates to trust kernel modules/sysexts/etc. should not require
> > going down the trust levels. The OS should be able to establish its
> > own trust to those pieces or reject them independently. It should
> > certainly trust everything the lower levels trust, but there's no
> > reason to not allow the higher levels to establish their own scoped
> > trust.
> >
> > This is the flaw we have right now: we can't do that.
>
> Of course there's a reason to only allow a fully validated trust chain - not only that, but it's the very basic of the entire model, and without it the entire premise falls flat on its face.
> The way to enroll your own certs is via firmware-mediated mechanisms such as shim+mok, and via built-in trusted keyring. Adding arbitrary trust anchors at the OS level completely ignores the foundational principle of the whole thing.

Your concept only works in *some* enterprise hardware where it's even
possible to have full control without breaking something. Even in my
server gear, I can't do that without breaking the network firmware. If
I can't safely distrust Microsoft reliably, then it's already broken.

Firmware trust has been broken since the very beginning, and it was
broken by design in the PC world.

Consumer PC equipment is even worse off because of how Microsoft's
Windows requirements influence how UEFI implementations work.



--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue




[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