linux-kernel - Re: [PATCH v4 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: <fcb30226f378ef12cd8bd15938f0af0e1a3977a2.camel@kernel.org>
Date:   Thu, 19 Aug 2021 14:38:03 +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 v4 00/12] Enroll kernel keys thru MOK

On Wed, 2021-08-18 at 20:20 -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
> 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.
> 
> 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
> 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.

As of today, I can use a prebuilt kernel, crate my own MOK key and sign
modules. What will be different?

> 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 .mok. It also adds a new MOK variable to shim.

I would name it as ".machine" because it is more "re-usable" name, e.g.
could be used for similar things as MOK. ".mok" is a bad name because
it binds directly to a single piece of user space software.

/Jarkko