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;
Date:   Wed, 15 Aug 2018 15:49:32 -0400
From:   Vivek Goyal <vgoyal@redhat.com>
To:     Yannik Sembritzki <yannik@sembritzki.me>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        David Howells <dhowells@redhat.com>,
        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
Message-ID: <20180815194932.GD29541@redhat.com>
References: <20180815100053.13609-1-yannik@sembritzki.me>
 <CA+55aFx2goMXj7rQg-qx-puiiWYJmkDMU1xniWEu6ikDBNgfdQ@mail.gmail.com>
 <654fbafb-69da-cd9a-b176-7b03401e71c5@sembritzki.me>
 <20180815174247.GB29541@redhat.com>
 <20180815185812.GC29541@redhat.com>
 <b2649b70-37b6-3929-a9d0-3d82033b2686@sembritzki.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b2649b70-37b6-3929-a9d0-3d82033b2686@sembritzki.me>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Aug 15, 2018 at 09:06:13PM +0200, Yannik Sembritzki wrote:
> 
> > 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)?
> >
> "User loaded ones" should not be trusted in general to prevent rootkits
> and similar from modifying the kernel (even if they have root).
> 
> According to the patch which introduced the secondary keyring (the one
> you mentioned), the requirements for adding keys to the secondary
> keyring are as follows:
> "Add a secondary system keyring that can be added to by root whilst the
> system is running - provided the key being added is vouched for by a key
> built into the kernel or already added to the secondary keyring."
> 

Right.

So it will become a question of should we trust a key which is
possibly dynamically loaded into the kernel, and which has been
trusted by an existing key. So this sounds like extending chain of
trust to a key which is dynamically loaded later. I feels reasonable
to me to extend chain of trust for kexec kernel. (Until and unless
somebody has a use case in mind where this is not a good idea).

I see that module signing code trusts only builtin keys and
not the keys in secondary_trusted_keys keyring.

Dave, what's the reason behind having two keyrings. Is it because
module signing code does not want to trust keys other than built-in
ones?

Thanks
Vivek


> I personally don't see a reason for this split, as the requirements for
> the secondary keyring are as strict as it can get. However, I'm new to
> this, so feel free to correct me.
> 
> Yannik
>