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

[Vivek Goyal <vgoyal@redhat.com>]

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
>