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: <490941a5197bf4bcf0d6f95610085ee4d46ed9bb.camel@linux.ibm.com>
Subject: Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Eric Snowberg <eric.snowberg@oracle.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>
Date:   Thu, 08 Jul 2021 15:31:10 -0400
In-Reply-To: <21EFCB58-2D89-4D30-8DA2-B952A7E1B1BD@oracle.com>
References: <20210707024403.1083977-1-eric.snowberg@oracle.com>
         <42b787dd3a20fe37c4de60daf75db06e409cfb6d.camel@linux.ibm.com>
         <5BFB3C52-36D4-47A5-B1B8-977717C555A0@oracle.com>
         <886f30dcf7b3d48644289acc3601c2f0207b19b6.camel@linux.ibm.com>
         <D34A6328-91CA-4E1E-845C-FAC9B424819B@oracle.com>
         <c0cf7f883a9252c17427f1f992e4973e78481304.camel@linux.ibm.com>
         <21EFCB58-2D89-4D30-8DA2-B952A7E1B1BD@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Eric,

On Thu, 2021-07-08 at 11:59 -0600, Eric Snowberg wrote:
> 
> >  Asumming a
> > function similar to "restrict_link_by_builtin_and_secondary_trusted" is
> > defined to include the MOK keyring, the CA keys in the MOK db would be
> > loaded onto the MOK keyring, the other keys that meet the secondary
> > keyring restriction would be loaded directly onto the secondary
> > keyring[1], and as you currently have, the remaining keys onto the
> > platform keyring.
> > 
> > This eliminates the exemption needed for loading keys onto the
> > secondary keyring.  The MOK keyring, containing just CA keys, becomes a
> > new trust source.
> 
> I just want to make sure I understand. If we kept the .mok keyring around, 
> we would store it into the system_keyring code, just like the platform 
> keyring is stored.  This would allow the move exemption code to be removed.
> If the mok keyring is a new trust source, whenever the secondary keyring 
> is referenced in verify_ code, the mok keyring will be checked too.  If 
> I have this right, let me know and I’ll work on a v2.  Thanks.

All the firmware keys are loaded onto the "platform" keyring, without
any restriction.  Your reference point should be the "builtin" and
"secondary" keyrings, not the "platform" keyring.

Changes:
- defining a new keyring restriction which only allows CA keys to be
loaded onto the MOK keyring.
- defining a new keyring restriction something along the lines of
"restrict_link_by_builtin_mok_and_secondary_trusted()".

In the case of "restrict_link_by_builtin_and_secondary_trusted()", it's
based on a build time option.  In the case of MOK, it might be both a
build time and runtime firmware variable option.  There are quite a few
permutations that will somehow need to be addressed:  secondary keyring
not defined, but MOK keyring defined, and the reverse.

Once all the CA keys in the MOK db are loaded onto the MOK keyring,
there will be no need for moving keys to the secondary keyring.  The
secondary keyring restriction will just work.  The main question is
whether there will need to be two passes.   One pass to first load all
the CA keys onto the MOK keyring.  A second pass to load the keys onto
the secondary keyring, based on the keyring restriction, and the
remaining ones onto the "platform" keyring to avoid the regression.

[Once the CA keys are loaded onto the MOK keyring, userspace will be
able to load certificates, signed by a key on the MOK keyring, onto the
secondary keyring.]

thanks,

Mimi