Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1253104

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

Show all headers | View raw

On Wed, 2015-10-21 at 13:21 -0400, Josh Boyer wrote:
> On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> >> Here's a set of patches that changes how keys are determined to be trusted
> >> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> >> it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> >> indicates that only keys with this flag set may be added to that keyring.
> >>
> >> Further, any time an X.509 certificate is instantiated without this flag
> >> set, the certificate is judged against the contents of the system trusted
> >> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
> >>
> >> With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
> >> implicitly trusted keys to a trusted-only keyring by asserting
> >> KEY_ALLOC_TRUSTED when the key is created,
> >
> > Ok, but only the x509 certificates built into the kernel image should be
> > automatically trusted and can be added to a trusted keyring, because the
> > kernel itself was signed (and verified).  These certificates extend the
> > (UEFI) certificate chain of trust that is rooted in hardware to the OS.
> 
> That doesn't sound accurate to me.  The cert built into the kernel
> image doesn't extend the UEFI certificates.  In most cases, it is a
> ephemeral cert that is automatically generated at kernel build time
> and then discarded.  It is not chained to or derived from any of the
> UEFI certs stored in the db (or mok) variables.  The built-in cert is
> used for module loading verification.  I agree that it should be
> trusted, but not really for the reason you list.  Perhaps you meant
> the key that the PE image of the kernel is signed with?  If so, the
> kernel doesn't load that.  Only shim (and grub2 via shim) read that
> key.

This is similar to the concept of the MoK DB.  Keys added to the MoK
aren't signed by a UEFI key, yet they extend the UEFI secure boot
certificate chain of trust.  Similarly, the certificates built into the
kernel image don't need to be signed by a UEFI/MoK key for it to extend
the certificate chain of trust.

> However, that does bring up the UEFI db/mok certs and how to deal with
> those.  The out-of-tree patches we have add them to the system keyring
> as trusted keys.  We can modify the patches to use KEY_ALLOC_TRUSTED
> to preserve that functionality I suppose.

Certificates are use case specific.  Just because a key was trusted at
the UEFI layer doesn't mean it should be trusted by the kernel (eg.
Microsoft key).  To illustrate this point, David Howells/David Woodhouse
recently posted/upstreamed patches to differentiate how keys loaded onto
the system keyring may be used. (Reference needed.)

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 00/10] KEYS: Change how keys are determined to be trusted David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 04/10] KEYS: Allow authentication data to be stored in an  asymmetric key David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 02/10] PKCS#7: Make trust determination dependent on  contents of trust keyring David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 06/10] X.509: Retain the key verification data David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 03/10] KEYS: Add facility to check key trustworthiness upon  link creation David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 08/10] PKCS#7: Make the signature a pointer rather than  embedding it David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 09/10] X.509: Move the trust validation code out to its own  file David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 07/10] X.509: Extract signature digest and make self-signed  cert checks earlier David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 05/10] KEYS: Add identifier pointers to public_key_signature  struct David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 01/10] KEYS: Generalise system_verify_data() to provide  access to internal content David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  [PATCH 10/10] KEYS: Move the point of trust determination to  __key_link() David Howells <dhowells@redhat.com> - 2015-10-21 17:20 +0200
  Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-10-21 19:10 +0200
    Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted Josh Boyer <jwboyer@fedoraproject.org> - 2015-10-21 19:30 +0200
      Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-10-21 20:20 +0200
        Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted Josh Boyer <jwboyer@fedoraproject.org> - 2015-10-21 20:30 +0200
          Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-10-21 20:40 +0200
    Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted Petko Manolov <petkan@mip-labs.com> - 2015-10-21 21:20 +0200

csiph-web