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


Groups > linux.kernel > #1253117

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

From Mimi Zohar <zohar@linux.vnet.ibm.com>
Newsgroups linux.kernel
Subject Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted
Date 2015-10-21 20:40 +0200
Message-ID <qm6sO-2SJ-19@gated-at.bofh.it> (permalink)
References <qm3lf-6Rp-1@gated-at.bofh.it> <qm53H-ZN-3@gated-at.bofh.it> <qm5n4-1m0-13@gated-at.bofh.it> <qm69s-2wo-25@gated-at.bofh.it> <qm6j9-2HH-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, 2015-10-21 at 14:21 -0400, Josh Boyer wrote:
> On Wed, Oct 21, 2015 at 2:11 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > 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
> 
> Right, because UEFI is verifying shim, which verifies grub2, which
> verifies the kernel.  I get that.  However, it's irrelevant.
> 
> > kernel image don't need to be signed by a UEFI/MoK key for it to extend
> > the certificate chain of trust.
> 
> The certificates built _into_ the kernel need to be trusted in all
> cases.  It is how module signing is done.  So a user not using Secure
> Boot, or even not using UEFI, still needs those embedded certs trusted
> so that they can load modules.  It has nothing to do with UEFI or some
> single-root-of-trust.
> 
> At any rate, I believe we are both saying the embedded cert needs to
> be trusted so there's little point in debating further.  I just wanted
> to point out that this need has nothing to do with UEFI.

Right, the embedded certs need to trusted.  But that trust needs to be
based on something.  One method of establishing that trust is (UEFI)
secure boot, which verifies the kernel image signature, including the
embedded certs.

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 | NextPrevious 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