Since this discussion affects which keys can be added to trusted keyrings, cc'ing linux-ima-devel. On Fri, 2016-12-02 at 10:57 -0800, James Bottomley wrote: > On Thu, 2016-11-24 at 11:17 -0800, James Bottomley wrote: > > On Mon, 2016-11-21 at 16:16 +0000, Ard Biesheuvel wrote: > > > On 16 November 2016 at 18:11, David Howells <dhowells@xxxxxxxxxx> > > > wrote: > > > > From: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> > > > > > > > > Secure Boot stores a list of allowed certificates in the 'db' > > > > variable. This imports those certificates into the system trusted > > > > keyring. This allows for a third party signing certificate to > > > > be used in conjunction with signed modules. By importing the > > > > public certificate into the 'db' variable, a user can allow a > > > > module signed with that certificate to load. The shim UEFI > > > > bootloader has a similar certificate list stored in the > > > > 'MokListRT' variable. We import those as well. > > > > > > > > > > This sounds like a bad idea to me. For the standard databases like > > > db and dbx, we can rely on the firmware to ensure that they are > > > what you expect. > > > > Actually, I think it's a bad idea for the opposite reason: Shim > > explicitly pivots the root of trust away from the db keys to its own > > Moklist keys. We have no choice and are forced to trust db for the > > secure boot part, but once we're in the kernel proper, I'd argue that > > we would only want to trust the pivoted root, i.e. Moklist. > > > > Trusting both could generate unwanted consequences, like pressure on > > Microsoft to sign modules or worse, pressure on OEMs to include > > module keys or hashes ... or worst of all OEMs signing external > > modules. > > > > > For MokListRt, not so much: anyone with sufficient > > > capabilities can generate such a variable from userland, and not > > > every arch/distro combo will be using shim and/or mokmanager. (The > > > debates are still ongoing, but my position is that there is no need > > > for shim at all on ARM given that the M$ problem only exists on > > > x86) > > > > OK, so on this point, I'm already not using Shim on my x86 box. > > However, what you find if you're using grub is that because grub > > doesn't do signature verification, you still have to use the shim > > protocol callout, so you need something between UEFI and grub to load > > at least this protocol. I suppose this would go away once we can > > persuade grub to verify signatures. > > Hm, that got crickets. > > Let me propose an alternative mechanism then. > > My problem is that although I am forced to trust the secure boot keys > for the UEFI security boundary, I don't necessarily want to trust them > for signing things for my kernel, so I want to pivot (or at > leastselectively weed out) keys. Shim already has this concept > partially with MokIgnoreDB. > > For the purposes of the kernel, I think we simply need a variable, lets > call it MokKernelCerts, that gives the list of certificates to import > into the kernel keyring. I think this variable should be BS NV only > (not RT) meaning we have to collect it before ExitBootServices(). The > reason for this is to ensure it's populated by a trusted entity within > the UEFI secure boot boundary. This will cause a kexec problem, so we > might have to relax this and use a RT shadow as we already do for > MokList. The idea is that we populate the kernel certificates only > from this variable, so policy can be decided by the bootloader (or > something else which runs within the secure boot environment). > > You can stop reading here if you're not interested in *how* this policy > would work. > > To make it work, Shim or one of the other intermediates would set up > the variable. we could communicate policy to it with the usual Foo, > FooUpdate mechanism we already use for MokList. The default policy (if > the variable doesn't exist on firstboot) can be whatever the distro > wants, so if Fedora wants all the secure boot certs, it can do that and > other distros can follow their own stricter or less strict policies. > The user would be able to overwrite this using the Update process, > which could be password verified like MokList already is. > > Does this sound acceptable to everyone? -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
