Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <cedc77fefdf22b2cec086f3e0dd9cc698db9bca2.camel@kernel.org>
Subject: Re: [PATCH v4 00/12] Enroll kernel keys thru MOK
From:   Jarkko Sakkinen <jarkko@kernel.org>
To:     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>
Date:   Mon, 23 Aug 2021 20:51:39 +0300
In-Reply-To: <e7e251000432cf7c475e19c56b0f438b92fec16e.camel@linux.ibm.com>
References: <20210819002109.534600-1-eric.snowberg@oracle.com>
         <fcb30226f378ef12cd8bd15938f0af0e1a3977a2.camel@kernel.org>
         <f76fcf41728fbdd65f2b3464df0821f248b2cba0.camel@linux.ibm.com>
         <91B1FE51-C6FC-4ADF-B05A-B1E59E20132E@oracle.com>
         <e7e251000432cf7c475e19c56b0f438b92fec16e.camel@linux.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.36.5-0ubuntu1 
MIME-Version: 1.0
Precedence: bulk

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:
> > >=20
> > > 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 e=
ach
> > > > > architecture.  Each end-user may use this kernel in entirely diff=
erent
> > > > > ways.  Some downstream kernels have chosen to always trust platfo=
rm keys
> > > > > within the Linux trust boundary for kernel module signing.  These
> > > > > kernels have no way of using digital signature base IMA appraisal=
.
> > > > >=20
> > > > > 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.
> > > >=20
> > > > 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 becau=
se
> > > > it binds directly to a single piece of user space software.
> > >=20
> > > Nayna previously said,
> > >   "I believe the underlying source from where CA keys are loaded migh=
t vary=20
> > >   based on the architecture (".mok" is UEFI specific.). The key part =
is=20
> > >   that this new keyring should contain only CA keys which can be late=
r=20
> > >   used to vouch for user keys loaded onto IMA or secondary keyring at=
=20
> > >   runtime. It would be good to have a "ca" in the name, like .xxxx-ca=
,=20
> > >   where xxxx can be machine, owner, or system. I prefer .system-ca."
> > >=20
> > > 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 reaso=
n,
> > > I agree naming the new keyring "mok" should be avoided.
> >=20
> > As I said previously, I=E2=80=99m open to renaming, I just would like t=
o have an=20
> > agreement on the new name before changing everything.  The current prop=
osed=20
> > names I have heard are =E2=80=9C.machine" and ".system-ca".  Is there a=
 preference=20
> > the maintainers feel is appropriate?  If so, please let me know and I=
=E2=80=99ll=20
> > rename it. Thanks.
> >=20
>=20
> 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=20
is "ca aspect of the name" anyway?

/Jarkko