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]

Message-ID: <CACdnJuuGusfnEXHY-rEeH5BNefsZHQk1xNJPK2SgXaw4prtt4Q@mail.gmail.com>
Date:   Sun, 6 Aug 2017 20:23:42 -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 Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> Matthew Garrett <mjg59@...gle.com> writes:
>> 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
>
> Not at all!  You can validate them in userspace.

And then you need an entire trusted userland, at which point you can
assert that the modules are trustworthy without having to validate
them so you don't need CONFIG_MODULE_SIG anyway.

>> 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.
>
> With your patch, you don't get tainting in the environment where you can
> verify.

You don't anyway, do you? Loading has already failed before this point
if sig_enforce is set.

> You'd be better adding a sysctl or equiv. to turn off force loading, and
> use that in your can-verify system.

I'm not sure what you mean by "force loading" here - if sig_enforce is
set, you can't force load an unsigned module. If sig_enforce isn't
set, you'll taint regardless of whether or not you force.

Wait. Hang on - are you confusing CONFIG_MODULE_SIG with CONFIG_MODVERSIONS?