On 12/22/22 12:00, Luca Boccassi 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. As Neal mentioned earlier, these mechanisms are often broken. Not only does some firmware wind up bricking the machine when they are used, they also may not support removing the key used to sign Windows. If the attacker can boot Windows and measured boot is not in use, they have won. A much better approach is to install a TPM-generated key in the TPM’s NVRAM, with a policy that only allows the key to be used once a trusted operating system has booted. That can be used as a trust anchor even without support from buggy UEFI firmware. Furthermore, measured boot allows tying e.g. LUKS keys to a combination of the actual OS booted and a passphrase needed to unlock the TPM. This allows the TPM’s protection against brute-force attacks to be used. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
