On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Do, 22.12.22 10:43, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering > > <mzerqung@xxxxxxxxxxx> wrote: > > > > > > On Do, 22.12.22 05:38, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > > > > > > > I understand the big issue you have is that the certificate store for > > > > > Linux (i.e. the mokutil db) is limited in size because EFI variable > > > > > NVRAM is limited in size? If that's the big issue you are having then > > > > > that's absolutely something the Linux community can fix, and can > > > > > address. Specifically, shim could allow storing the cert store on > > > > > disk, and authenticate it at boot via the TPM. Not trivial, but > > > > > doable. And certainly not the firmware's fault... > > > > > > > > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if > > > > > the way Linux/shim/mokutil implement the cert db is done the way it is > > > > > currently done. > > > > > > > > Frankly, I'm aggravated by the increased reliance on UEFI features > > > > without fixing Linux's problems with UEFI features. If we stopped > > > > relying on UEFI for the cert store, a lot of my issues would go away, > > > > because then we can design better workflows for managing > > > > certificates. > > > > > > Well, the thing is: a chain of trust is a *chain*, hence you must > > > ultimately hook validation to what the firmware provides you with as > > > root. And that ultimately is the SecureBoot db on commodity hardware. > > > > > > If I buy a boring laptop at a store it will come with a UEFI cert > > > store, and nothing else. Linux cannot really ignore that. If it did, > > > then you'd not have a trusted boot chain, hence the whole excercsie > > > would be pointless. > > > > > > > Shim trusts MS and the main distro cert, grub is trusted from there, > > then the OS trusts those and anything else the admin adds. That's how > > It should work. Trust chains are sensible as long as they're > > extensible. > > Hmm, that chain is partly backwards? it's the firmware that has to > trust the msft cert which trusts shim, which trusts the distro cert, > which trusts grub and the kernel. The thing that comes first > at boot must trust the next, otherwise we'd have to boot into > untrusted stuff first, which really misses the point? not grokking > what you are trying tosay? > 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. -- 真実はいつも一つ！/ 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
