linux-kernel - Re: [PATCH v4 00/12] Enroll kernel keys thru MOK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc37d1da3ef5aae16e69eeda25d6ce6fe6a51a77.camel@HansenPartnership.com>
Date:   Wed, 25 Aug 2021 15:27:18 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Nayna <nayna@...ux.vnet.ibm.com>,
        Eric Snowberg <eric.snowberg@...cle.com>,
        David Howells <dhowells@...hat.com>
Cc:     keyrings@...r.kernel.org,
        linux-integrity <linux-integrity@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>,
        James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn" <serge@...lyn.com>, keescook@...omium.org,
        gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
        scott.branden@...adcom.com, weiyongjun1@...wei.com,
        nayna@...ux.ibm.com, ebiggers@...gle.com, ardb@...nel.org,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        lszubowi@...hat.com, linux-kernel@...r.kernel.org,
        linux-crypto@...r.kernel.org,
        linux-security-module@...r.kernel.org, pjones@...hat.com,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        Patrick Uiterwijk <patrick@...terwijk.org>
Subject: Re: [PATCH v4 00/12] Enroll kernel keys thru MOK

On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote:
> On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote:
> > > > > 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.
> > 
> > Sounds good to me.  Jarkko?
> > 
> > thanks,
> > 
> > Mimi
> 
> I just wonder what you exactly gain with "_ca"?

Remember, a CA cert is a self signed cert with the CA:TRUE basic
constraint.  Pretty much no secure boot key satisfies this (secure boot
chose deliberately NOT to use CA certificates, so they're all some type
of intermediate or leaf), so the design seems to be only to pick out
the CA certificates you put in the MOK keyring.  Adding the _ca suffix
may deflect some of the "why aren't all my MOK certificates in the
keyring" emails ...

James