linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: keyrings@vger.kernel.org,
	linux-integrity <linux-integrity@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	James Morris <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	keescook@chromium.org, gregkh@linuxfoundation.org,
	torvalds@linux-foundation.org, scott.branden@broadcom.com,
	weiyongjun1@huawei.com, nayna@linux.ibm.com, ebiggers@google.com,
	ardb@kernel.org, nramas@linux.microsoft.com, lszubowi@redhat.com,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	James.Bottomley@HansenPartnership.com, pjones@redhat.com,
	glin@suse.com, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok
Date: Thu, 12 Aug 2021 16:10:35 -0600	[thread overview]
Message-ID: <F792F96B-C482-4F28-A984-A6B5F49C3A56@oracle.com> (raw)
In-Reply-To: <58e6e03b69b8fadfb854669086020c633837be88.camel@linux.ibm.com>


> On Aug 12, 2021, at 1:46 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> Hi Eric,
> 
> On Wed, 2021-08-11 at 22:18 -0400, Eric Snowberg wrote:
>> With the introduction of the mok keyring, the end-user may choose to
>> trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
>> trust them, the .mok keyring will contain these keys.  If not, the mok
>> keyring will always be empty.  Update the restriction check to allow the
>> secondary trusted keyring to also trust mok keys.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> v3: Initial version
>> ---
>> certs/system_keyring.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index cb773e09ea67..8cc19a1ff051 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
>> 	if (!restriction)
>> 		panic("Can't allocate secondary trusted keyring restriction\n");
>> 
>> -	restriction->check = restrict_link_by_builtin_and_secondary_trusted;
>> +	restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;
>> 
>> 	return restriction;
>> }
> 
> Not everyone needs to build a generic kernel, like the distros.  As
> previously discussed, not everyone is willing to trust the new MOK
> keyring nor the UEFI variable for enabling it.  For those environments,
> they should be able to totally disable the MOK keyring.
> 
> Please define a Kconfig similar to "CONFIG_SECONDARY_TRUSTED_KEYRING"
> for MOK.  The "restriction" would be based on the new Kconfig being
> enabled.

Yes, I can add that.  Currently there is a Kconfig to enable the secondary 
and another for IMA to trust the secondary.  Would you like to see two new 
Kconfig options added?  One that allows the secondary to use the mok as a new 
trust  source and another for IMA to trust the mok keyring.  Or a single Kconfig 
that handles both?  Thanks.


  reply	other threads:[~2021-08-12 22:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12  2:18 [PATCH v3 00/14] Enroll kernel keys thru MOK Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 01/14] integrity: Introduce a Linux keyring for the Machine Owner Key (MOK) Eric Snowberg
2021-08-12 18:58   ` Jarkko Sakkinen
2021-08-12 22:16     ` Eric Snowberg
2021-08-13 18:26     ` Nayna
2021-08-12 21:31   ` Mimi Zohar
2021-08-12 22:36     ` Eric Snowberg
2021-08-13  0:35       ` Mimi Zohar
2021-08-12  2:18 ` [PATCH v3 02/14] KEYS: CA link restriction Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 03/14] integrity: Trust MOK keys if MokListTrustedRT found Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 04/14] integrity: add add_to_mok_keyring Eric Snowberg
2021-08-12 19:32   ` Jarkko Sakkinen
2021-08-12 22:04     ` Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 05/14] integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_ca Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 06/14] integrity: accessor function to get trust_moklist Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 07/14] integrity: add new keyring handler for mok keys Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 08/14] KEYS: add a reference to mok keyring Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 09/14] KEYS: Introduce link restriction to include builtin, secondary and mok keys Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok Eric Snowberg
2021-08-12 19:46   ` Mimi Zohar
2021-08-12 22:10     ` Eric Snowberg [this message]
2021-08-12 22:14       ` Mimi Zohar
2021-08-12  2:18 ` [PATCH v3 11/14] KEYS: link secondary_trusted_keys to mok trusted keys Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 12/14] integrity: Do not allow mok keyring updates following init Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 13/14] integrity: store reference to mok keyring Eric Snowberg
2021-08-12  2:18 ` [PATCH v3 14/14] integrity: change ima link restriction to include mok keys Eric Snowberg

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=F792F96B-C482-4F28-A984-A6B5F49C3A56@oracle.com \
    --to=eric.snowberg@oracle.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ardb@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=ebiggers@google.com \
    --cc=glin@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=keyrings@vger.kernel.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lszubowi@redhat.com \
    --cc=nayna@linux.ibm.com \
    --cc=nramas@linux.microsoft.com \
    --cc=pjones@redhat.com \
    --cc=scott.branden@broadcom.com \
    --cc=serge@hallyn.com \
    --cc=torvalds@linux-foundation.org \
    --cc=weiyongjun1@huawei.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).