On Tue, 2016-07-26 at 15:42 +0100, David Woodhouse wrote:
> On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > 
> > > Oops, "Signature management - keys, modules, firmware" was a
> > > suggestion
> > > from last year, but in my opinion still very apropos.
> > 
> > Yup, definitely - especially with secure boot starting to firm up 
> > on the ARM side there's a bunch more interest in it from more 
> > embedded applications.
> 
> Are we going to propose this again "formally" (i.e. sufficiently
> clearly that the committee take note and consider it)?

Heh, we've got lots of people wanting to participate, but no-one really
wanting to make the proposal, so I'll try.

internal kernel key management is becoming a bit of an uncontrolled
mess.  We have several sources of trusted keys: the secure boot keyring
(called the db database), the internal keys the kernel was compiled
with, keys in the TPM which are declared to the kernel (this is another
whole world of pain because adding this damaged the current TPM key
management infrastructure from userspace), IMA keys (used for file
integrity measurement), authentication and encryption keys (things like
keys used to encrypt the disk, authenticate NFS roots etc).

There are several issues

   1. Population and update policy: How should we populate the default
      keyrings and revocation lists?  Should we have a built in list of
      absolute trust that can never be added to? I think the current
      default here is OK: it's populate with the kernel built in keys and
      nothing else.  If userspace wants to populate with, say, the secure
      boot keys, then it can do so from init.  An issue here is the
      Microsoft signing key, which most Linux people have but which they
      wouldn't necessarily consider to be a source of absolute trust. 
       However, third party driver vendors would like a way to get their
      key trusted by the kernel so they can easily supply modules (This
      isn't a binary module issue: the code is usually GPL, but the
      vendors would like to supply updates asynchronously to the distro
      release cycle).  We can say their key should be added as part of the
      rpm that installs the module, but do users really want this key
      adding to the default keyring to be trusted for non-module
      operations?
   2. Virtualization of the keyrings.  The issue here is that you don't
      necessarily want root in a container to have full access to the
      kernel keyrings.  It looks to me like we can use a simple per
      namespace virtualization of the key permissions, but I don't think
      this should be a topic of discussion before it has been proposed and
      discussed on the containers list (which no-one has done yet, in
      spite of my requesting).
   3. Integration with existing key management infrastructures.  The issue
      here is things like the gnome keyring and the TPM.  The TPM is a
      particularly thorny problem: as a key store, the TPM has a very
      limited storage space, so something has effectively to swap keys in
      and out as they're used.  This function is currently performed by a
      userspace stack called the TSS.  However, the kernel use of the TPM
      effectively steals the nvram resource behind the manager's back and
      can lead to resource starvation issues in the TPM and unexpected
      responses back to the user space TSS.  If the kernel wants to use
      TPM keys, it needs either to request them properly from the TSS or
      we need to pull TPM key management fully into the kernel and make
      the TSS use it.
   4. Our current key type model is slightly confusing, because we have
      about 18 different ones from specific key types: assymetric, secure,
      encrypted confused with use case key types like: cifs.spnego,
      dns_resolver and grouping types like keyring.  We should probably
      document them all somewhere and encourage subsystems which don't use
      them (like dm crypt) to start.  We might also consider discouraging
      key type proliferation?
   5. root (uid 0) access: should root be able to modify any keyring?

Probably a ton more issues I forgot, but others can add them.  A
precursor to this discussion should probably be an introductory
presentation about how this all currently works.  If you can't answer
the question how do I add a key to the kernel for a signed module, you
need the introductory session ...

James