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:   Thu, 16 Aug 2018 14:51:27 +0100
From:   David Howells <dhowells@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     dhowells@...hat.com, Vivek Goyal <vgoyal@...hat.com>,
        yannik@...britzki.me, 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

Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > I see that module signing code trusts only builtin keys and
> > not the keys in secondary_trusted_keys keyring.
> 
> This, I think, makes sense.
> 
> 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.

At the risk of starting another flamewar...

The problem with that is that it means you can't load third party modules -
such as the NVidia driver.  That's fine if you absolutely reject the right of
people to produce third party drivers for the Linux kernel and absolutely
require that they open and upstream their code if they want in.

One of the reasons *for* letting modules be loaded using UEFI keys is that
this allows you to load signed third-party drivers without needing to manually
re-sign your shim, grub and kernel.

But this is not something we can ask most ordinary users to do (not least
because of key material security) - and they would have to at least partially
repeat the process every time one of those components is upgraded.  One of the
jobs of a distribution is to insulate the ordinary user from this.

And before anyone says "well, the distribution should just build and sign
$THIRD_PARTY_MODULE", there are issues with that that potentially come with
lawyers attached.

Further, if you want to go down the route of restricting the use of UEFI keys
to load modules because that might allow someone to run hacked code, then you
also can't let kexec use UEFI keys because that would then be able to run
hacked code too.

As an alternative, though, maybe it would make sense to allow TPM-based keys
to be used to verify modules.  The problem there is that it doesn't prevent
the signing process from being interfered with on an already-hacked box.

David