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: <873794x9v0.fsf@rustcorp.com.au>
Date:   Mon, 07 Aug 2017 14:17:15 +0930
From:   Rusty Russell <rusty@...tcorp.com.au>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     linux-kernel@...r.kernel.org, jeyu@...nel.org
Subject: Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett <mjg59@...gle.com> writes:
> 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.

Yep.  But your patch already gives userland that power, to silently load
unsigned modules.

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

No.  You used to get a warning and a taint when you had a kernel
configured to expect signatures and it didn't get one.  You want to
remove that warning, to silently accept unsigned modules.

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

No, I mean stripping the signatures.  (I thought modprobe could do this
these days, but apparently not!)

So, you're actually building the same kernel, but building two sets of
modules: one without signatures, one with?

And when deploying the one with signatures, you're setting sig_enforce.
On the other, you don't want signatures because um, reasons?  And you
want to suppress the message?

This seems so convoluted already, I can see how you considered an
upstream patch your most productive path forward.

But it's possible that this scenario makes sense to Jeyu and I'm just
incapable of seeing its beauty?

Cheers,
Rusty.