On Thu, 4 Jul 2024 at 16:41, Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote: > > On Thu, 4 Jul 2024 at 16:21, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, 2024-06-17 at 23:00 +0100, luca.boccassi@xxxxxxxxx wrote: > > > From: Luca Boccassi <bluca@xxxxxxxxxx> > > > > > > Add a new configuration > > > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING > > > that enables verifying dm-verity signatures using the platform > > > keyring, which is populated using the UEFI DB certificates. This is > > > useful for self-enrolled systems that do not use MOK, as the > > > secondary keyring which is already used for verification, if the > > > relevant kconfig is enabled, is linked to the machine keyring, which > > > gets its certificates loaded from MOK. On datacenter/virtual/cloud > > > deployments it is more common to deploy one's own certificate chain > > > directly in DB on first boot in unattended mode, rather than relying > > > on MOK, as the latter typically requires interactive authentication > > > to enroll, and is more suited for personal machines. > > > > I think that's true if you roll your own cloud OS. If you rely on a > > distro OS (as, say, IBM Cloud does) you do use shim/mok and actually > > you als have to enroll all the driver module keys in MoK. > > Yes, that is true, in many cases shim + 2nd stage is still used in > those environments. Perhaps a better use case I should have mentioned > is: this is also useful for those who self-enroll, and do not use > shim/mok at all. This is actually quite common, for example it's the > main way Arch users do SecureBoot, and there's an entire ecosystem > around this workflow, using sbctl and friends. systemd-boot provides > facilities to self-enroll on first boot, for example. > Another use case is in CIs, where we boot with a locally built > systemd-boot, self-enroll in EDK2, run some tests, and then throw away > the VM. This is the case in systemd's upstream CI that uses mkosi, for > example. > > > > Default to the same value as > > > DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING > > > if not otherwise specified, as it is likely that if one wants to use > > > MOK certificates to verify dm-verity volumes, DB certificates are > > > going to be used too. Keys in DB are allowed to load a full kernel > > > already anyway, so they are already highly privileged. > > > > But there's a reason we allow mok users to distrust DB through mokutil. > > It's because although you might be OK with these keys guarding the pre- > > boot environment (because if they don't do that Microsoft will be > > unhappy) and transferring control to SHIM via these keys, you wouldn't > > necessarily trust the owner of these keys to tamper with your kernel or > > install modules. Doesn't a similar reasoning apply to dm-verity root > > hash signing? > > Yes, although to me it personally feels like the real benefit of that > is avoiding being too exposed to the kitchen sink that is the UEFI 3rd > party CA, more than protection against an intentionally malicious CA > owner, after all if you are malicious and control the first stage of > the chain of trust things are very dire at that point. However, this > is all moot because of the next point that you correctly raised: > > > By the way, if I look at how the machine keyring is handled, db certs > > won't get added if MokIgnoreDB is set by shim, so I think the behaviour > > of this patch is correct, and it's just the wording above that may be > > misleading. > > This is of course entirely correct, and I should have worded the > commit message better to reflect it. I'll send v2 with these updates. > Thanks for the review! Ah it looks like this was merged yesterday in dm/for-next, so a bit late to update the commit message. Fortunately it's not wrong per-se, just missing a couple of useful bits of information :-)
