linux-kernel - Re: [RFC PATCH 0/3] Add additional MOK vars

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, 21 May 2021 07:44:52 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>, keyrings@...r.kernel.org,
        linux-integrity <linux-integrity@...r.kernel.org>
Cc:     David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        dmitry.kasatkin@...il.com, James Morris <jmorris@...ei.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        torvalds@...ux-foundation.org,
        "Serge E . Hallyn" <serge@...lyn.com>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        pjones@...hat.com, glin@...e.com,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        Patrick Uiterwijk <patrick@...terwijk.org>
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars

[Cc'ing Patrick Uiterwijk]

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:
> > On May 20, 2021, at 6:22 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:

> > I really do understand the need for extending the root of trust beyond
> > the builtin keys and allowing end user keys to be loaded onto a kernel
> > keyring, but it needs to be done safely.  The first step might include
> > locally signing the MOK keys being loaded onto the secondary keyring
> > and then somehow safely providing the local-CA key id to the kernel.
> 
> If the machine owner and Linux distributor are independent of one another,
> I don’t see how MOK key signing could work.  There wouldn’t be a way for
> the kernel to verify the end-user supplied signed MOK key.  An end-user 
> choosing a Linux distro is trusting the company/organization building the 
> kernel, but the trust doesn’t go the other way.  Do you have a solution 
> in mind on how this would be possible? If you do, I’m happy to move in
> a different direction to solve this problem.

We are working with the distros to address this problem.  The first
attempt at extending the secondary keyring's root of trust relied on a
TPM2 NV Index[1].

Using MOK is a possible alternative, if it can be done safely.  For
example, if the boot command line could be protected from modification,
the end-user could enroll a key in MOK and identify the specific MOK
key on the boot command line[2].  The boot command line would then
become an additional root of trust source.

The root of trust for loading keys on the different trusted keyrings
are self documenting -  restrict_link_by_builtin_trusted,
restrict_link_by_builtin_and_secondary_trusted().  A new function would
need to be defined to include the boot command line as a new or
additional root of trust source.

thanks,

Mimi

[1] https://lore.kernel.org/linux-integrity/20210225203229.363302-1-patrick@puiterwijk.org/
[2] Perhaps extend the existing "ca_keys" boot command line option.