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: <CACdnJutPrDvYtssnc=yVvWa_4oTRvigUhK+5J8s941oAoJDT6Q@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ