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> 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
