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 21:06:13 +0200
From:   Yannik Sembritzki <yannik@...britzki.me>
To:     Vivek Goyal <vgoyal@...hat.com>
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


> 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."

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