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]

Date:   Wed, 15 Aug 2018 15:49:32 -0400
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Yannik Sembritzki <yannik@...britzki.me>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        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>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        Matthew Garrett <mjg59@...gle.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform
 keys to boot

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
>