Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1534429345.3166.1.camel@HansenPartnership.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom
 platform keys to boot
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     David Howells <dhowells@redhat.com>,
        Vivek Goyal <vgoyal@redhat.com>
Cc:     Yannik Sembritzki <yannik@sembritzki.me>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Peter Anvin <hpa@zytor.com>,
        the arch/x86 maintainers <x86@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
        "Justin M. Forbes" <jforbes@redhat.com>,
        Peter Jones <pjones@redhat.com>,
        Matthew Garrett <mjg59@google.com>
Date:   Thu, 16 Aug 2018 07:22:25 -0700
In-Reply-To: <4911.1534421610@warthog.procyon.org.uk>
References: <20180815185812.GC29541@redhat.com>
         <20180815100053.13609-1-yannik@sembritzki.me>
         <CA+55aFx2goMXj7rQg-qx-puiiWYJmkDMU1xniWEu6ikDBNgfdQ@mail.gmail.com>
         <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me>
         <20180815174247.GB29541@redhat.com>
         <4911.1534421610@warthog.procyon.org.uk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 2018-08-16 at 13:13 +0100, David Howells wrote:
> Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> > Now this patch changed it to trusting builtin_trusted_keys by
> > default, and all the other keys go to secondary_trusted_keys
> > kerying. And that probably explains why it broke.
> > 
> > So checking for keys in both the keyrings makes sense to me. 
> > 
> > I am wondering why did we have to split this keyring to begin
> > with. So there are use cases where we want to trust builtin keys
> > but not the ones which came from other places (UEFI secure boot db,
> > or user loaded one)?
> 
> IMA and the IMA authors.  They want everything separated into
> separate keyrings out by source and usage as far as I can tell -
> though this just makes it harder to use things.

Hey, it's not just IMA people.  I've told you several times you can't
use the secure boot keys for any form of trust beyond boot, so if you
want to add them to the kernel they have to be in a lesser trusted
keyring.  Anyone who values their security wants to be very careful
what the UEFI keys are trusted for ... it's not just IMA signatures as
the module signing discussion shows.

Personally, I don't see any use for the UEFI keys in the kernel beyond
kexec (where you can actually get the key directly from the UEFI
variable), so I'd prefer not to load them and not to have a secondary
keyring.

> One advantage of splitting things, though, is that you don't lose the
> built-in keys if you load a conflicting one from another source.
> 
> One thing that's on my to-do list is to mark keys with the
> provenance, perhaps
> something like:
> 
> 	enum key_source {
> 	     key_added_by_user,
> 	     key_built_in_for_modsign,
> 	     key_added_to_image,
> 	     key_from_uefi_db,
> 	     key_from_uefi_dbx,
> 	     key_from_tpm,
> 	};
> 
> 	struct key {
> 		...
> 		enum key_source	source;
> 	};
> 
> Then:
> 
>  (1) pass this information to LSMs to make use of
> 
>  (2) Make the verification code take a bitmask of what keys are
> permitted for
>      the task at hand.

Sounds reasonable,

James