linux-kernel - Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT found

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: <4A479B96-4B41-4323-9920-5A909423F998@oracle.com>
Date:   Thu, 10 Nov 2022 00:54:43 +0000
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Morten Linderud <morten@...derud.pw>
CC:     "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "weiyongjun1@...wei.com" <weiyongjun1@...wei.com>,
        Nayna Jain <nayna@...ux.ibm.com>,
        Eric Biggers <ebiggers@...gle.com>,
        "ardb@...nel.org" <ardb@...nel.org>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        "lszubowi@...hat.com" <lszubowi@...hat.com>,
        "jason@...c4.com" <jason@...c4.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "James.Bottomley@...senpartnership.com" 
        <James.Bottomley@...senpartnership.com>,
        "pjones@...hat.com" <pjones@...hat.com>,
        Konrad Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT
 found



> On Nov 9, 2022, at 5:01 PM, Morten Linderud <morten@...derud.pw> wrote:
> 
> On Tue, Nov 23, 2021 at 11:41:23PM -0500, Eric Snowberg wrote:
>> A new Machine Owner Key (MOK) variable called MokListTrustedRT has been
>> introduced in shim. When this UEFI variable is set, it indicates the
>> end-user has made the decision themselves that they wish to trust MOK keys
>> within the Linux trust boundary.  It is not an error if this variable
>> does not exist. If it does not exist, the MOK keys should not be trusted
>> within the kernel.
> 
> Hi Eric,
> 
> I've been milling around on this patch-set for a while and I have a few issues
> with the description of the commit and what the code actually does.
> 
> efi_mokvar_entry_find doesn't simply read an UEFI variable as the commit message
> suggests, it will look for the MOK variable loaded into the EFI configuration
> table. This implies we need this table setup in early boot to take usage of this
> patch set.
> 
> The only bootloader that does setup this table, is the `shim` as described. But
> no other bootloader implements support for the MOK EFI configuration table.
> 
> This effectively means that there is still no way for Machine Owners to load
> keys into the keyring, for things like module signing, without the shim present
> in the bootchain. I find this a bit weird.
> 
> Is this an intentional design decision, or could other ways be supported as
> well?

In v6 I had it as a RT variable, during the review a request was made [1] to just 
use the EFI configuration table.  If there are other boot loaders that want to use this,
I don’t see why the code in v6 couldn’t be added back.  If the configuration table isn’t
available, it could try reading the RT var next.

1. https://patchwork.kernel.org/project/linux-integrity/patch/20210914211416.34096-13-eric.snowberg@oracle.com/#24453409