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: <1ca6772b-46e0-9d93-0e15-7cf73a0b7b3f@sembritzki.me>
Date:   Wed, 15 Aug 2018 23:08:04 +0200
From:   Yannik Sembritzki <yannik@...britzki.me>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Vivek Goyal <vgoyal@...hat.com>
Cc:     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 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 15.08.2018 22:47, Linus Torvalds wrote:
> It basically says: we don't allow modules that weren't built with the
> kernel. Adding a new key later and signing a module with it violates
> that premise.

Considering the following scenario:
A user is running a distro kernel, which is built by the distro, and has
the distro signing key builtin (i.e. fedora). Now, the user has taken
ownership of their system and provisioned their own platform key.
Accordingly, the user signs the distro kernel with their own key.

If I understand you correctly, modules signed by the users own key, but
not signed with the distro key, will stop working in this case?

IMO, this is not okay. The layer of trust should extend from the bottom
(user-provisioned platform key) up. Only trusting the kernel builtin key
later on (wrt. kernel modules) contradicts this principal.

Yannik