linux-kernel - Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

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: <1534429345.3166.1.camel@HansenPartnership.com>
Date:   Thu, 16 Aug 2018 07:22:25 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     David Howells <dhowells@...hat.com>,
        Vivek Goyal <vgoyal@...hat.com>
Cc:     Yannik Sembritzki <yannik@...britzki.me>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Peter Anvin <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
        "Justin M. Forbes" <jforbes@...hat.com>,
        Peter Jones <pjones@...hat.com>,
        Matthew Garrett <mjg59@...gle.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom
 platform keys to boot

On Thu, 2018-08-16 at 13:13 +0100, David Howells wrote:
> Vivek Goyal <vgoyal@...hat.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