linux-kernel - Re: [RFC PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED

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: <20140211234534.6bc34e57@gandalf.local.home>
Date:	Tue, 11 Feb 2014 23:45:34 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	David Howells <dhowells@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH] Fix: module signature vs tracepoints: add new
 TAINT_UNSIGNED_MODULE

On Tue, 11 Feb 2014 08:27:38 +0100
Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
> > Users have reported being unable to trace non-signed modules loaded 
> > within a kernel supporting module signature.
> 
> External modules should strive to get out of the 'crap' and
> 'felony law breaker' categories and we should not make it
> easier for them to linger in a broken state.
> 
> Nacked-by: Ingo Molnar <mingo@...nel.org>

I'm not sure how great this idea is, but it isn't the same as the
"crap" and "fenony law breaker" categories. Having a non-signed module
doesn't mean that it isn't fully GPL compliant, it just means that it
hasn't been signed. There's several things that can taint the kernel
when loading a module. Being non GPL compliant is just one of them, and
that will never be allowed to accept tracepoints.

Forcing a module that was built for a different kernel version gives us
another taint, which we don't add tracepoints for, not because it is
not compliant, but because that could corrupt the kernel as we can
not guarantee the binary structure layout of those modules would be the
same as what the kernel was built with. We don't want people
complaining about tracepoint failures due to forcing an older module
into a newer kernel with different tracepoint structures.

But if the kernel expects to have signed modules, and you force a
module to be loaded that is not signed, then you still get that
"forced" module taint, which is the same one as loading a module from
an older kernel into a newer kernel. It's a different problem, and I
can see having a different taint flag be more informative to kernel
developers in general. I would welcome that change with or without
letting tracepoints be set for that module.

But I have to ask Mathieu, what exactly is the use case here? If you
have a kernel that expects to only load signed modules, why would you
want to force non signed ones? That basically breaks the whole purpose
of signing modules. Once you allow a non signed module to be loaded
then the kernel can be considered compromised. That is, you just gave
kernel access to an untrusted source.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/