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:   Thu, 15 Feb 2018 19:36:45 +0000
From:   Matthew Garrett <mjg59@...gle.com>
To:     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

On Thu, Feb 15, 2018 at 7:25 AM Jessica Yu <jeyu@...nel.org> wrote:
> I'm still unclear on why a distro would enable CONFIG_MODULE_SIG and
> then _not_ want to know about unsigned modules.

The same kernel image may be used in situations where the use case benefits
from enforcement of module signatures and cases where it doesn't -
distributions don't generally have the resources to ship multiple kernel
packages with lightly modified configurations.

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

> I understand this predicament, but it seems like adding a new set of
> options/parameters like this is just hiding the symptoms of the
> problem (modules distributed by Debian getting tainted by default)
> instead of fixing what seems to be the heart of the issue (Debian
> doesn't support their own module signing yet), if that makes sense.
> I am hesitant about merging something that would only serve as a
> temporary solution until Debian supports their own module signing. In
> that case, I would prefer the Debian folks to maintain their own patch
> removing the taint until they support module signing for their own
> modules, especially if - and please correct me if I'm wrong - the
> new option is not going to see long-term usage.

I'd expect this option to be used by distributions for as long as
distributions need to support use-cases that don't need signed modules, so
probably forever.