linux-kernel - Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

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:   Sun, 6 Aug 2017 10:34:13 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     Rusty Russell <rusty@...tcorp.com.au>
Cc:     linux-kernel@...r.kernel.org, jeyu@...nel.org
Subject: Re: [PATCH] Allow automatic kernel taint on unsigned module load to
 be disabled

On Sat, Aug 5, 2017 at 11:54 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> Matthew Garrett <mjg59@...gle.com> writes:
>> Distributions may wish to provide kernels that permit loading of
>> unsigned modules based on certain policy decisions.
>
> Sorry, that's way too vague to accept this patch.
>
> So I'm guessing a binary module is behind this vagueness.  If you want
> some other method than signing to vet modules, please do it in
> userspace.  You can do arbitrary things that way...

Binary modules will still be tainted by the license checker. The issue
is that if you want to enforce module signatures under *some*
circumstances, you need to build with CONFIG_MODULE_SIG, but that
changes the behaviour of the kernel even when you're not enforcing
module signatures. The same kernel may be used in environments where
you can verify the kernel and environments where you can't, and in the
latter you may not care that modules are unsigned. In that scenario,
tainting doesn't buy you anything.