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.