On Thu, 2024-07-04 at 16:41 +0100, Luca Boccassi wrote: > On Thu, 4 Jul 2024 at 16:21, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: [...] > > 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, That's precisely correct. We trust the regulation of the pre-boot environment but don't want to encourage people to think db certs should be usable outside it. > 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: I think we mostly agree the 3rd party CA is reasonably well regulated. The problem is actually OEMs and ODMs that add their own certs to DB outside of the 3rd party CA control (mostly so their own EFI tooling will run). In theory they're still regulated by the MS Hardware Compatibility requirements, but we don't want them getting the idea that they can suddenly also sign linux kernel binary modules or additional IMA policies or add trusted keys to the system keyrings ... James
