On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi <bl...@debian.org> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to