linux-kernel - Re: inherit TAINT_PROPRIETARY

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]

Date:   Sat, 01 Aug 2020 01:16:30 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     Christoph Hellwig <hch@....de>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jessica Yu <jeyu@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: inherit TAINT_PROPRIETARY_MODULE v2

On July 31, 2020 11:53:08 PM PDT, Christoph Hellwig <hch@....de> wrote:
>[note: private reply now to start a flame fest with the usual suspects]

[You still CCed LKML.]

>On Fri, Jul 31, 2020 at 01:11:46PM -0700, josh@...htriplett.org wrote:
>> Christoph Hellwig wrote:
>> > we've had a bug in our resolution of _GPL modules since day one, that
>> > is a module can claim to be GPL licensed and use _GPL exports, while
>> > it also depends on symbols from non-GPL modules.  This is used as a
>> > circumvention of the _GPL exports by using a small shim module using
>> > the _GPL exports and the other functionality.
>> 
>> This looks great. You might also consider doing the reverse: if a module
>> imports any EXPORT_SYMBOL_GPL symbols, any symbols that module in turn
>> exports shouldn't be importable by any module that doesn't explicitly
>> claim to be GPL-compatible. Effectively, if a module imports any
>> EXPORT_SYMBOL_GPL symbols, all of its exported symbols would then be
>> treated as EXPORT_SYMBOL_GPL.
>> 
>> This would catch the case of attempting to "wrap" EXPORT_SYMBOL_GPL
>> symbols in the other direction, by re-exporting the same or similar
>> functions to another module. (This would help catch mistakes, not just
>> intentional malice.)
>
>I'd personally 100% agree with that, but I'd rather clear it with Linus
>privately first.  This would basically make most of the usual
>modular subsystems unavailable to proprietary modules as all of them
>use _GPL driver core exports, and I suspect he'd cave into the screaming.

As a start, what about applying that logic specifically to out-of-tree modules? That would address the shim problem. The justification would be that in-tree modules have at least gone through some level of review on what they're exporting.

(Standard disclaimer: suggesting enhancements to the symbol licensing framework should not be taken as implicit endorsement of any legitimacy for non-GPL-compatible modules.)