LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nayna <nayna@linux.vnet.ibm.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Eric Snowberg <eric.snowberg@oracle.com>,
	David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org,
	linux-integrity <linux-integrity@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	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,
	Lakshmi Ramasubramanian <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 <James.Bottomley@HansenPartnership.com>,
	pjones@redhat.com,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Patrick Uiterwijk <patrick@puiterwijk.org>
Subject: Re: [PATCH v4 00/12] Enroll kernel keys thru MOK
Date: Mon, 23 Aug 2021 16:48:11 -0400	[thread overview]
Message-ID: <bffb33a3-d5b5-f376-9d7d-706d38357d1a@linux.vnet.ibm.com> (raw)
In-Reply-To: <cedc77fefdf22b2cec086f3e0dd9cc698db9bca2.camel@kernel.org>


On 8/23/21 1:51 PM, Jarkko Sakkinen wrote:
> On Thu, 2021-08-19 at 13:32 -0400, Mimi Zohar wrote:
>> On Thu, 2021-08-19 at 09:23 -0600, Eric Snowberg wrote:
>>>> On Aug 19, 2021, at 7:10 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>
>>>> On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote:
>>>>> On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote:
>>>>>> Downstream Linux distros try to have a single signed kernel for each
>>>>>> architecture.  Each end-user may use this kernel in entirely different
>>>>>> ways.  Some downstream kernels have chosen to always trust platform keys
>>>>>> within the Linux trust boundary for kernel module signing.  These
>>>>>> kernels have no way of using digital signature base IMA appraisal.
>>>>>>
>>>>>> This series introduces a new Linux kernel keyring containing the Machine
>>>>>> Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim.
>>>>> I would name it as ".machine" because it is more "re-usable" name, e.g.
>>>>> could be used for similar things as MOK. ".mok" is a bad name because
>>>>> it binds directly to a single piece of user space software.
>>>> Nayna previously said,
>>>>    "I believe the underlying source from where CA keys are loaded might vary
>>>>    based on the architecture (".mok" is UEFI specific.). The key part is
>>>>    that this new keyring should contain only CA keys which can be later
>>>>    used to vouch for user keys loaded onto IMA or secondary keyring at
>>>>    runtime. It would be good to have a "ca" in the name, like .xxxx-ca,
>>>>    where xxxx can be machine, owner, or system. I prefer .system-ca."
>>>>
>>>> The CA keys on the MOK db is simply the first root of trust being
>>>> defined, but other roots of trust are sure to follow.  For this reason,
>>>> I agree naming the new keyring "mok" should be avoided.
>>> As I said previously, I’m open to renaming, I just would like to have an
>>> agreement on the new name before changing everything.  The current proposed
>>> names I have heard are “.machine" and ".system-ca".  Is there a preference
>>> the maintainers feel is appropriate?  If so, please let me know and I’ll
>>> rename it. Thanks.
>>>
>> Jarkko, I think the emphasis should not be on "machine" from Machine
>> Owner Key (MOK), but on "owner".  Whereas Nayna is focusing more on the
>> "_ca" aspect of the name.   Perhaps consider naming it
>> "system_owner_ca" or something along those lines.
> What do you gain such overly long identifier? Makes no sense. What
> is "ca aspect of the name" anyway?

As I mentioned previously, the main usage of this new keyring is that it 
should contain only CA keys which can be later used to vouch for user 
keys loaded onto secondary or IMA keyring at runtime. Having ca in the 
name like .xxxx_ca, would make the keyring name self-describing. Since 
you preferred .system, we can call it .system_ca.

Thanks & Regards,

        - Nayna


  reply	other threads:[~2021-08-23 20:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19  0:20 Eric Snowberg
2021-08-19  0:20 ` [PATCH v4 01/12] integrity: Introduce a Linux keyring for the Machine Owner Key (MOK) Eric Snowberg
2021-08-19  0:20 ` [PATCH v4 02/12] integrity: Do not allow mok keyring updates following init Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 03/12] KEYS: CA link restriction Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 04/12] integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_ca Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 05/12] integrity: add new keyring handler for mok keys Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 06/12] KEYS: add a reference to mok keyring Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 07/12] KEYS: Introduce link restriction to include builtin, secondary and mok keys Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 08/12] KEYS: integrity: change link restriction to trust the mok keyring Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 09/12] KEYS: link secondary_trusted_keys to mok trusted keys Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 10/12] integrity: store reference to mok keyring Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 11/12] integrity: Trust MOK keys if MokListTrustedRT found Eric Snowberg
2021-08-19  0:21 ` [PATCH v4 12/12] integrity: Only use mok keyring when uefi_check_trust_mok_keys is true Eric Snowberg
2021-08-19 11:38 ` [PATCH v4 00/12] Enroll kernel keys thru MOK Jarkko Sakkinen
2021-08-19 13:10   ` Mimi Zohar
2021-08-19 15:23     ` Eric Snowberg
2021-08-19 17:32       ` Mimi Zohar
2021-08-23 17:51         ` Jarkko Sakkinen
2021-08-23 20:48           ` Nayna [this message]
2021-08-24 14:34             ` Mimi Zohar
2021-08-25 22:21               ` Jarkko Sakkinen
2021-08-25 22:27                 ` James Bottomley
2021-08-27 20:44                   ` Nayna
2021-08-30 17:39                     ` Eric Snowberg
2021-09-01  0:52                       ` Nayna
2021-09-01  1:51                         ` Eric Snowberg
2021-09-02 10:18                           ` Mimi Zohar
2021-09-01  4:34                     ` Jarkko Sakkinen
2021-09-01  4:36                       ` Jarkko Sakkinen
2021-09-01  4:46                         ` Jarkko Sakkinen
2021-08-23 17:37       ` Jarkko Sakkinen
2021-08-23 17:35     ` Jarkko Sakkinen
2021-08-23 17:48       ` 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=bffb33a3-d5b5-f376-9d7d-706d38357d1a@linux.vnet.ibm.com \
    --to=nayna@linux.vnet.ibm.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=eric.snowberg@oracle.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=patrick@puiterwijk.org \
    --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 \
    --subject='Re: [PATCH v4 00/12] Enroll kernel keys thru MOK' \
    /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

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).