Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Mi, 2016-07-27 at 16:15 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 3:54 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> Again, I think that wrapping this up in the "keyring" term is
> problematic.  I'm saying that I can see a use case for allowing a
> brand new key (not rooted anywhere in particular) to be added to the
> list of trusted signing keys for modules so long as a PCR is extended
> with that key.  That would let me seal things to a non-tampered-kernel
> configuration by sealing them against an unextended PCR such that a
> user who loaded a module not signed by the initial trusted key would
> not be able to unseal the secrets.

Nice!  Ok, you create a key that is sealed to a set of PCRs and then
extend a PCR with a hash of the key.  Normally extending the PCR is to
prevent the key from being unsealed again.  In this case, I assume
you're preventing other keys from being created based on the initial
PCRs.  So you now have a key that matches an initial set of PCRs.  That
key can then be used to sign the kernel modules.  On reboot, the key is
unsealed iff the PCRs match.

If you're creating a TPM based key on the local host, that would require
your signing kernel modules locally.   With keyrings, the key for kernel
modules is already baked into the kernel and is loaded onto the builtin
keyring.  For code that the key isn't baked into the kernel, instead of
signing the code directly, the third party keys, which were used to sign
the code, would be signed by a key on the builtin keyring.

Mimi