linux-kernel - Re: [PATCH RFC v2 10/12] KEYS: link system_trusted_keys to mok_trusted

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:   Fri, 06 Aug 2021 11:18:31 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>
Cc:     keyrings@...r.kernel.org,
        linux-integrity <linux-integrity@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        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,
        Lakshmi Ramasubramanian <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,
        glin@...e.com, "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
Subject: Re: [PATCH RFC v2 10/12] KEYS: link system_trusted_keys to
 mok_trusted_keys

On Fri, 2021-08-06 at 09:00 -0600, Eric Snowberg wrote:
> > On Aug 5, 2021, at 9:19 PM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> > 
> > On Thu, 2021-08-05 at 19:29 -0600, Eric Snowberg wrote:
> > 
> >>> From the thread discussion on 00/12:
> >>> 
> >>> Only the builtin keys should ever be on the builtin keyring.  The
> >>> builtin keyring would need to be linked to the mok keyring.  But in the
> >>> secondary keyring case, the mok keyring would be linked to the
> >>> secondary keyring, similar to how the builtin keyring is linked to the
> >>> secondary keyring.
> >>> 
> >>>       if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
> >>>               panic("Can't link trusted keyrings\n");
> >> 
> >> 
> >> This part is confusing me though.
> >> 
> >> Here are some of the tests I’m performing with the current series:
> >> 
> >> Initial setup:
> >> Create and enroll my own key into the MOK.
> >> Sign a kernel, kernel module and IMA key with my new CA key.
> >> Boot with lockdown enabled (to enforce sig validation).
> >> 
> >> Kernel built with CONFIG_SECONDARY_TRUSTED_KEYRING=y
> >> 
> >> $ keyctl show %:.secondary_trusted_keys
> >> Keyring
> >> 530463486 ---lswrv      0     0  keyring: .secondary_trusted_keys
> >> 411466727 ---lswrv      0     0   \_ keyring: .builtin_trusted_keys
> >> 979167715 ---lswrv      0     0   |   \_ asymmetric: Build time autogenerated kernel key: 07a56e29cfa1e21379aff2c522efff7d1963202a
> >> 534573591 ---lswrv      0     0   |   \_ asymmetric: Oracle-CA: Oracle certificate signing key: aeefb4bfde095cacaabff81dd266974b1b4e23b8
> >> 968109018 ---lswrv      0     0   \_ keyring: .mok
> >> 857795115 ---lswrv      0     0       \_ asymmetric: Erics-CA: UEK signing key: 9bfa6860483aa46bd83f7fa1289d9fc35799e93b
> >> 
> >> With this setup I can:
> >> * load a kernel module signed with my CA key
> >> * run "kexec -ls" with the kernel signed with my CA key
> >> * run "kexec -ls" with a kernel signed by a key in the platform keyring
> >> * load another key into the secondary trusted keyring that is signed by my CA key
> >> * load a key into the ima keyring, signed by my CA key
> >> 
> >> Kernel built without CONFIG_SECONDARY_TRUSTED_KEYRING defined
> >> 
> >> $ keyctl show %:.builtin_trusted_keys
> >> Keyring
> >> 812785375 ---lswrv      0     0  keyring: .builtin_trusted_keys
> >> 455418681 ---lswrv      0     0   \_ keyring: .mok
> >> 910809006 ---lswrv      0     0   |   \_ asymmetric: Erics-CA: UEK signing key: 9bfa6860483aa46bd83f7fa1289d9fc35799e93b
> >> 115345009 ---lswrv      0     0   \_ asymmetric: Oracle-CA: Oracle certificate signing key: aeefb4bfde095cacaabff81dd266974b1b4e23b8
> >> 513131506 ---lswrv      0     0   \_ asymmetric: Build time autogenerated kernel key: 22353509f203b55b84f15d0aadeddc134b646185
> >> 
> >> With this setup I can:
> >> * load a kernel module signed with my CA key
> >> * run "kexec -ls" with the kernel signed with my CA key
> >> * run "kexec -ls" with a kernel signed by a key in the platform keyring
> >> * load a key into the ima keyring, signed by my CA key
> >> 
> >> So why would the linking need to be switched?  Is there a test I’m
> >> missing?  Thanks.
> > 
> > It's a question of semantics.  The builtin keyring name is self
> > describing.  It should only contain the keys compiled into the kernel
> > or inserted post build into the reserved memory.  Not only the kernel
> > uses the builtin keyring, but userspace may as well[1].  Other users of
> > the builtin keyring might not want to trust the mok keyring as well.
> 
> Should this feature only work with kernels built with 
> CONFIG_SECONDARY_TRUSTED_KEYRING defined?  If so, I could drop support in 
> the next version for kernels built without it.

Support for loading the CA keys stored in the MOK db onto the mok
keyring, only if the secondary keyring is configured would really
simplify the code.   Support for using the mok  keyring without the
secondary keyring being configured, could always be added later.  As
long as the other distros agree, I'm all for it.

thanks,

Mimi