linux-kernel - Re: [PATCH v5 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: <17C81066-DBE8-4DB0-B66B-822BF6EFF67C@oracle.com>
Date:   Wed, 8 Sep 2021 11:09:44 -0600
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>
Cc:     keyrings@...r.kernel.org,
        linux-integrity <linux-integrity@...r.kernel.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        David Howells <dhowells@...hat.com>,
        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,
        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" <konrad.wilk@...cle.com>
Subject: Re: [PATCH v5 00/12] Enroll kernel keys thru MOK


> On Sep 8, 2021, at 10:03 AM, Jarkko Sakkinen <jarkko@...nel.org> 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.

I am using terminology used previously by others when addressing this issue.  
If I should be using different terminology, please advise. The kernel does not 
trust pre-boot keys within it, meaning these pre-boot keys can not be used to 
validate items within the kernel. This is the “trust boundary”. Preboot keys are
on one side of the boundary, compiled-in keys are on the other.  MOK keys are 
pre-boot keys.  Currently they can not be used to validate things within the 
kernel itself (kernel modules, IMA keys, etc).