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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1519225147.2617.169.camel@decadent.org.uk>
Date:   Wed, 21 Feb 2018 15:59:07 +0100
From:   Ben Hutchings <ben@...adent.org.uk>
To:     Matthew Garrett <mjg59@...gle.com>, Jessica Yu <jeyu@...nel.org>
Cc:     Rusty Russell <rusty@...tcorp.com.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Make kernel taint on invalid module signatures
 configurable

On Tue, 2018-02-20 at 20:37 +0000, Matthew Garrett wrote:
> On Tue, Feb 20, 2018 at 11:21 AM Jessica Yu <jeyu@...nel.org> wrote:
[...]
> > In any case, I think I'd be willing to merge it as a module_param made
> > available under CONFIG_MODULE_SIG=y (rather than as a new separate config
> > option), while preserving the default behavior of tainting on
> > unsigned/invalidly signed module loads (so let's keep the param parts of
> > your patch). I think it makes sense to consider the turning-off-the-taint
> > param as a behavioral tweak under CONFIG_MODULE_SIG. Then you could turn
> > off the tainting behavior on the kernel command line, would this sufficient
> > enough for your use cases?
>
> I think that's probably not practical - distributions often aren't in
> control of the kernel command line after initial installation, so they'd
> end up with different behaviour depending on whether a machine was a clean
> install or not (which is why several things that are module_params have
> defaults controlled by additional kernel config options)

Indeed.  So long as Debian doesn't do module signing, the default
behaviour in our kernel images will need to be that they don't complain
about lack of signatures.

[...]
> > > 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 thought these two cases (particularly #2) were the very situations
> > where distros might find the unsigned module taint useful (especially
> > in the use case where you do benefit from module signatures). From my
> > understanding, the unsigned module taint is intended to be useful when
> > looking at crashes/OOPses, to provide a clear indication of whether or
> > not a developer could reliably debug the crash, or choose to tread
> > carefully, because the end-user has loaded an unsigned/out-of-tree
> > module that wasn't signed/shipped by the distribution. Is the taint
> > just not useful to distros in this manner anymore?
> 
> The module list is usually sufficient for that - users tend not to replace
> individual distribution modules without rebuilding their entire kernel.

And we already have an O (out-of-tree) taint flag.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. ... I realized that a large part of my life from then on was
going to be spent in finding mistakes in my own programs. - Maurice
Wilkes, 1949


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)