linux-kernel - Re: [PATCH v6 00/13] 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]
Date:   Thu, 16 Sep 2021 19:58:48 -0600
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Peter Jones <pjones@...hat.com>
Cc:     Jarkko Sakkinen <jarkko@...nel.org>, 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,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
Subject: Re: [PATCH v6 00/13] Enroll kernel keys thru MOK


> On Sep 16, 2021, at 4:14 PM, Peter Jones <pjones@...hat.com> wrote:
> 
> On Thu, Sep 16, 2021 at 06:15:50PM +0300, Jarkko Sakkinen wrote:
>> On Wed, 2021-09-15 at 15:28 -0600, Eric Snowberg wrote:
>>>> On Sep 15, 2021, at 11:57 AM, Jarkko Sakkinen <jarkko@...nel.org> wrote:
>>>> 
>>>> On Tue, 2021-09-14 at 17:14 -0400, Eric Snowberg wrote:
>>>>> Back in 2013 Linus requested a feature to allow end-users to have the 
>>>>> ability "to add their own keys and sign modules they trust". This was
>>>>> his *second* order outlined here [1]. There have been many attempts 
>>>>> over the years to solve this problem, all have been rejected.  Many 
>>>>> of the failed attempts loaded all preboot firmware keys into the kernel,
>>>>> including the Secure Boot keys. Many distributions carry one of these 
>>>>> rejected attempts [2], [3], [4]. This series tries to solve this problem 
>>>>> with a solution that takes into account all the problems brought up in 
>>>>> the previous attempts.
>>>>> 
>>>>> On UEFI based systems, this series introduces a new Linux kernel keyring 
>>>>> containing the Machine Owner Keys (MOK) called machine. It also defines
>>>>> a new MOK variable in shim. This variable allows the end-user to decide 
>>>>> if they want to load MOK keys into the machine keyring. Mimi has suggested 
>>>>> that only CA keys contained within the MOK be loaded into the machine 
>>>>> keyring. All other certs will load into the platform keyring instead.
>>>>> 
>>>>> By default, nothing changes; MOK keys are not loaded into the machine
>>>>> keyring.  They are only loaded after the end-user makes the decision 
>>>>> themselves.  The end-user would set this through mokutil using a new 
>>>>> --trust-mok option [5]. This would work similar to how the kernel uses 
>>>>> MOK variables to enable/disable signature validation as well as use/ignore 
>>>>> the db. Any kernel operation that uses either the builtin or secondary 
>>>>> trusted keys as a trust source shall also reference the new machine 
>>>>> keyring as a trust source.
>>>>> 
>>>>> Secure Boot keys will never be loaded into the machine keyring.  They
>>>>> will always be loaded into the platform keyring.  If an end-user wanted 
>>>>> to load one, they would need to enroll it into the MOK.
>>>>> 
>>>>> Steps required by the end user:
>>>>> 
>>>>> Sign kernel module with user created key:
>>>>> $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
>>>>>  machine_signing_key.priv machine_signing_key.x509 my_module.ko
>>>>> 
>>>>> Import the key into the MOK
>>>>> $ mokutil --import machine_signing_key.x509
>>>>> 
>>>>> Setup the kernel to load MOK keys into the .machine keyring
>>>>> $ mokutil --trust-mok
>>>>> 
>>>>> Then reboot, the MokManager will load and ask if you want to trust the
>>>>> MOK key and enroll the MOK into the MOKList.  Afterwards the signed kernel
>>>>> module will load.
>>>>> 
>>>>> I have included links to both the mokutil [5] and shim [6] changes I
>>>>> have made to support this new functionality.
>>>> 
>>>> How hard it is to self-compile shim and boot it with QEMU (I
>>>> do not know even the GIT location of Shim)?
>>> 
>>> It is not hard, that is the setup I use for my testing.  Upstream shim 
>>> is located here [1].  Or you can use my repo which contains the necessary
>>> changes [2].
>>> 
>>> [1] https://github.com/rhboot/shim
>>> [2] https://github.com/esnowberg/shim/tree/mokvars-v2
>>> 
>> 
>> So, my 2nd Q would be: which order these should be upstreamed?
>> 
>> Linux patch set cannot depend on "yet to be upstreamed" things.
>> 
>> Code changes look good enough to me.
> 
> We can carry this support in shim before it's in kernel.  Eric's current
> patch for shim and mokutil looks mostly reasonable, though I see a few
> minor nits we'll have to sort out.

Thanks Peter.  Previously I had not sent it for a shim review since I wanted 
to make sure this approach had a path forward.  I’ll work on submitting the 
shim changes for review now.