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;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <20180815185812.GC29541@redhat.com>
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>
To:     Vivek Goyal <vgoyal@redhat.com>
Cc:     dhowells@redhat.com, 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>,
        James Bottomley <James.Bottomley@HansenPartnership.com>,
        Matthew Garrett <mjg59@google.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4910.1534421610.1@warthog.procyon.org.uk>
Date:   Thu, 16 Aug 2018 13:13:30 +0100
Message-ID: <4911.1534421610@warthog.procyon.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

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.

David