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

[Andy Lutomirski]

On Jul 27, 2016 8:17 PM, "Mimi Zohar" <zohar at linux.vnet.ibm.com> wrote:
>
> On Mi, 2016-07-27 at 16:15 -0700, Andy Lutomirski wrote:
> > On Wed, Jul 27, 2016 at 3:54 PM, Mimi Zohar <zohar at 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.

Not actually what I meant, but sure.  What I actually meant was that maybe
I have a secret (totally unrelated to kernel modules) that, by policy, I
should only be able to access on an un-tampered-with kernel.

With my little trick, I can still build and run random kernel modules.  If
I do so, though, I lose access to those protected secrets until reboot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160727/873bf31e/attachment.html>