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!
