Date:   Wed, 08 Sep 2021 19:49:06 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Eric Snowberg <eric.snowberg@...cle.com>, keyrings@...r.kernel.org,
        linux-integrity@...r.kernel.org, zohar@...ux.ibm.com,
        dhowells@...hat.com, dwmw2@...radead.org,
        herbert@...dor.apana.org.au, davem@...emloft.net,
        jmorris@...ei.org, serge@...lyn.com
Cc:     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, nramas@...ux.microsoft.com, lszubowi@...hat.com,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        James.Bottomley@...senPartnership.com, pjones@...hat.com,
        konrad.wilk@...cle.com
Subject: Re: [PATCH v5 00/12] Enroll kernel keys thru MOK

On Wed, 2021-09-08 at 19:03 +0300, Jarkko Sakkinen wrote:
> On Tue, 2021-09-07 at 12:00 -0400, Eric Snowberg wrote:
> > Many UEFI Linux distributions boot using shim.  The UEFI shim provides
> > what is called Machine Owner Keys (MOK).  Shim uses both the UEFI Secure
> > Boot DB and MOK keys to validate the next step in the boot chain.  The
> > MOK facility can be used to import user generated keys.  These keys can
> > be used to sign an end-user development kernel build.  When Linux boots,
> > pre-boot keys (both UEFI Secure Boot DB and MOK keys) get loaded in the
> > Linux .platform keyring.  
> > 
> > Currently, pre-boot keys are not trusted within the Linux trust boundary
> > [1]. These platform keys can only be used for kexec. If an end-user
> 
> What exactly is "trust boundary"? And what do you mean when you say that
> Linux "trusts" something? AFAIK, software does not have feelings. Please,
> just speak about exact things.
> 
> That's the whole point of the cover letter. It's better to not have cover
> letter at all, than a confusing cover letter that reads like a white paper.
> Code changes at least tell the exact story, and not speak about feelings.
> 
> > wants to use their own key within the Linux trust boundary, they must
> > either compile it into the kernel themselves or use the insert-sys-cert
> > script. Both options present a problem. Many end-users do not want to
> > compile their own kernels. With the insert-sys-cert option, there are
> > missing upstream changes [2].  Also, with the insert-sys-cert option,
> > the end-user must re-sign their kernel again with their own key, and
> > then insert that key into the MOK db. Another problem with
> > insert-sys-cert is that only a single key can be inserted into a
> > compressed kernel.
> 
> I use a pre-compiled kernel in my desktop: https://liquorix.net/. When
> a new version comes up it requires a sbsign one-liner to sign it for
> secure boot. I'm wondering what is the problem I'm facing because I do
> not see it.
> 
> If there are something missing changes that you use as a rationale for
> this large patch set, you should at least broadly explain what we are
> missing. How I conclude this paragraph is that, since there is only an
> xref, they are not really "that important" changes, which are missing.
> 
> > Having the ability to insert a key into the Linux trust boundary opens
> > up various possibilities.  The end-user can use a pre-built kernel and
> > sign their own kernel modules.  It also opens up the ability for an
> 
> Which both can be done by end-user as of today, or I'm misreading this.
> 
> > end-user to more easily use digital signature based IMA-appraisal.  To
> > get a key into the ima keyring, it must be signed by a key within the
> > Linux trust boundary.
> 
> What is IMA appraisal? I just don't know it because I don't use IMA.
> Again, this trust boundary is really something I do not. Looking at
> code changes, you could just speak about exact assets in the kernel.
> 
> > 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 .machine. It also adds a new MOK variable to shim.
> > This variable allows the end-user to decide if they want to trust keys
> > enrolled in the MOK within the Linux trust boundary.  By default,
> > nothing changes; MOK keys are not trusted within the Linux kernel.  They
> > are only trusted after the end-user makes the decision themselves.  The
> > end-user would set this through mokutil using a new --trust-mok option
> > [3]. This would work similar to how the kernel uses MOK variables to
> > enable/disable signature validation as well as use/ignore the db.
> 
> OK, changes are described here (again speaking about trusting tho). The
> motivation part is missing. The text before this is more like confusion
> part. When you describe motivation to do something you should really be in
> grass roots, e.g. "when you have this feature in the kernel, look, I can
> do now this". It's not that hard. E.g. with an usage example it is quite
> quick accomplish this.

The code changes overally make sense but this motivotional part is the
problem. E.g. if you do a pull request, it is completely *unusable* in
that context. In that case I would have to write something that should
have been the cover letter. It's 12 patches, so it is perfectly sensible
to ask a better one.

/Jarkko

Powered by blists - more mailing lists