linux-kernel - Re: [PATCH] Make kernel taint on invalid module signatures configurable

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:   Fri, 16 Feb 2018 09:24:58 +0100
From:   Philipp Hahn <pmhahn@...ahn.de>
To:     Matthew Garrett <mjg59@...gle.com>, Jessica Yu <jeyu@...nel.org>
Cc:     Ben Hutchings <ben@...adent.org.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Make kernel taint on invalid module signatures
 configurable

Hello,

Am 15.02.2018 um 20:36 schrieb Matthew Garrett:
> On Thu, Feb 15, 2018 at 7:25 AM Jessica Yu <jeyu@...nel.org> wrote:
>>  From what I understand from Ben's post from last year
>> (http://lkml.kernel.org/r/1504044122.4448.24.camel@decadent.org.uk),
>> it sounds like the main issue is that Debian doesn't support their own
>> centralised module signing yet, causing all of their modules to be
>> automatically tainted if they enable CONFIG_MODULE_SIG, and that a new
>> option like this would likely be used as a temporary "fix". Am I
>> understanding correctly?
> 
> Not entirely. There's two cases where the current situation causes problems:
> 
> 1) Distributions that build out of tree kernel modules and don't have
> infrastructure to sign them will end up with kernel taint. That's something
> that can be resolved by implementing that infrastructure.
> 2) End-users who build out of tree kernel modules will end up with kernel
> taint and will file bugs. This cannot be fixed but will increase
> distribution load anyway.

Just yesterday I sent the attached email to the crypto/-maintainers as I
have read some Fedora documentation about adding the UEFI SecureBoot
keys to the kernel secondary trusted keyring:
<https://docs-old.fedoraproject.org/en-US/Fedora/23/html/System_Administrators_Guide/sect-kernel-module-authentication.html>

Sadly didn't work for me :-(
If my understanding is correct and iff that would work, Debian (and
others) could load their public key into Shim and then use the
associated private key for singing their modules.

Debian currently plans to have a Sprint for their SecureBoot process in
April, which I will attend. Hopefully we will find a solution their:
<https://wiki.debian.org/Sprints/2018/SecureBootSprint>

Philipp (also a Debian developer)

Download attachment "Nachricht als Anhang" of type "message/rfc822" (2692 bytes)