All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	Robert Holmes <robeholmes@gmail.com>,
	jeyu@kernel.org, linux-kernel@vger.kernel.org
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] KEYS: Make use of platform keyring for module signature verify
Date: Thu, 25 Apr 2019 19:46:45 +0000	[thread overview]
Message-ID: <1556221605.24945.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <1556193350.3894.92.camel@linux.ibm.com>

On Thu, 2019-04-25 at 07:55 -0400, Mimi Zohar wrote:
> On Wed, 2019-04-24 at 14:33 +0000, Robert Holmes wrote:
> > This patch completes commit 278311e417be ("kexec, KEYS: Make use of
> > platform keyring for signature verify") which, while adding the
> > platform keyring for bzImage verification, neglected to also add
> > this keyring for module verification.
> > 
> > As such, kernel modules signed with keys from the MokList variable
> > were not successfully verified.
> 
> Using the platform keyring keys for verifying kernel modules was not
> neglected, but rather intentional.  This patch description should
> clearly explain the reason for needing to verify kernel module
> signatures based on the pre-boot keys.  (Hint: verifying kernel
> modules based on the pre-boot keys was previously rejected.)

To clarify here: most Linux systems use shim/mok to pivot the root of
trust away from the Secure Boot db variable to the new MokList/shim
built in keys.  This makes the actual secure boot db outside the
expected Linux Kernel trust boundary *unless* the user has taken
ownership of the system and is actually using db for their own trusted
keys.  This makes the policy for what pre-boot keys to trust within the
Linux boundary very complex, which is why we default to not using the
pre-boot keys at all.

James

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	Robert Holmes <robeholmes@gmail.com>,
	jeyu@kernel.org, linux-kernel@vger.kernel.org
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] KEYS: Make use of platform keyring for module signature verify
Date: Thu, 25 Apr 2019 12:46:45 -0700	[thread overview]
Message-ID: <1556221605.24945.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <1556193350.3894.92.camel@linux.ibm.com>

On Thu, 2019-04-25 at 07:55 -0400, Mimi Zohar wrote:
> On Wed, 2019-04-24 at 14:33 +0000, Robert Holmes wrote:
> > This patch completes commit 278311e417be ("kexec, KEYS: Make use of
> > platform keyring for signature verify") which, while adding the
> > platform keyring for bzImage verification, neglected to also add
> > this keyring for module verification.
> > 
> > As such, kernel modules signed with keys from the MokList variable
> > were not successfully verified.
> 
> Using the platform keyring keys for verifying kernel modules was not
> neglected, but rather intentional.  This patch description should
> clearly explain the reason for needing to verify kernel module
> signatures based on the pre-boot keys.  (Hint: verifying kernel
> modules based on the pre-boot keys was previously rejected.)

To clarify here: most Linux systems use shim/mok to pivot the root of
trust away from the Secure Boot db variable to the new MokList/shim
built in keys.  This makes the actual secure boot db outside the
expected Linux Kernel trust boundary *unless* the user has taken
ownership of the system and is actually using db for their own trusted
keys.  This makes the policy for what pre-boot keys to trust within the
Linux boundary very complex, which is why we default to not using the
pre-boot keys at all.

James


  parent reply	other threads:[~2019-04-25 19:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 14:33 [PATCH v2] KEYS: Make use of platform keyring for module signature verify Robert Holmes
2019-04-24 14:33 ` Robert Holmes
     [not found] ` <20190424160609.EE5ED21901@mail.kernel.org>
2019-04-24 17:36   ` Robert Holmes
2019-04-24 17:36     ` Robert Holmes
2019-04-25 11:55 ` Mimi Zohar
2019-04-25 11:55   ` Mimi Zohar
2019-04-25 18:21   ` Jeremy Cline
2019-04-25 18:21     ` Jeremy Cline
2019-04-25 19:46   ` James Bottomley [this message]
2019-04-25 19:46     ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1556221605.24945.3.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=jeyu@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robeholmes@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.