These exports have the power to change the implementations of all
syscalls and I've seen people exploiting this "feature".
Make the exports GPLonly (which some LSM folks agreed to
when it was merged initially to avoid that).
--- 1.2/security/security.c Wed Aug 28 22:52:56 2002
+++ edited/security/security.c Thu Oct 17 16:30:40 2002
@@ -241,9 +241,9 @@
return security_ops->sys_security (id, call, args);
}
-EXPORT_SYMBOL (register_security);
-EXPORT_SYMBOL (unregister_security);
-EXPORT_SYMBOL (mod_reg_security);
-EXPORT_SYMBOL (mod_unreg_security);
-EXPORT_SYMBOL (capable);
-EXPORT_SYMBOL (security_ops);
+EXPORT_SYMBOL_GPL(register_security);
+EXPORT_SYMBOL_GPL(unregister_security);
+EXPORT_SYMBOL_GPL(mod_reg_security);
+EXPORT_SYMBOL_GPL(mod_unreg_security);
+EXPORT_SYMBOL(capable);
+EXPORT_SYMBOL(security_ops);
On Thu, Oct 17, 2002 at 08:07:41AM -0700, Greg KH wrote:
> On Thu, Oct 17, 2002 at 03:35:05PM +0100, Christoph Hellwig wrote:
> > These exports have the power to change the implementations of all
> > syscalls and I've seen people exploiting this "feature".
> >
> > Make the exports GPLonly (which some LSM folks agreed to
> > when it was merged initially to avoid that).
>
> I would really, really, really like to make this change. Unfortunatly,
> one of the current copyright holders of this file does not agree with
> it.
>
> Crispin, for the benifit of the lkml readers, can you explain why WireX
> does not want this change?
It's GPLed. It doesn't matter who holds the copyright.
On Thu, Oct 17, 2002 at 03:35:05PM +0100, Christoph Hellwig wrote:
> These exports have the power to change the implementations of all
> syscalls and I've seen people exploiting this "feature".
>
> Make the exports GPLonly (which some LSM folks agreed to
> when it was merged initially to avoid that).
I would really, really, really like to make this change. Unfortunatly,
one of the current copyright holders of this file does not agree with
it.
Crispin, for the benifit of the lkml readers, can you explain why WireX
does not want this change?
thanks,
greg k-h
On Thu, Oct 17, 2002 at 03:35:05PM +0100, Christoph Hellwig wrote:
>These exports have the power to change the implementations of all
>syscalls and I've seen people exploiting this "feature".
Ug. If people are already jumping on this, that might be a good reason
to revert the entire LSM feature, if EXPORT_SYMBOL_GPL is not acceptable
to all copyright holders...
Sigh, I hate legal crap.
Jeff
On Thu, Oct 17, 2002 at 09:51:06AM -0700, Crispin Cowan wrote:
> My argument against the intent of this change is that no, I do not think
> we should restrict LSM modules to be GPL-only. LSM is an API for loading
> externally developed packages of software, similar to syscalls. There is
> benefit in permitting proprietary modules (you get additional modules
> that you would not get otherwise) just as there is benefit in permitting
> proprietary applications (you get Oracle, DB2, and WordPerfect).
My arguement is that I want this flag as a hint for authors of
propritary security modules that I'm going to sue them if they
use hook called from code I have copyright on. This includes such
central parts as vfs_read/vfs_write.
> no legal standing what so ever. If kernel module interfaces are held by
> a court to be linking, then export symbols are redundant. If kernel
> module interfaces are held by a court to be an interface, then the
> export symbols are just wrong.
It's a very clear hint, and very usefull as such.
Greg KH wrote:
>On Thu, Oct 17, 2002 at 03:35:05PM +0100, Christoph Hellwig wrote:
>
>
>>These exports have the power to change the implementations of all
>>syscalls and I've seen people exploiting this "feature".
>>
>>Make the exports GPLonly (which some LSM folks agreed to
>>when it was merged initially to avoid that).
>>
>>
>I would really, really, really like to make this change. Unfortunatly,
>one of the current copyright holders of this file does not agree with
>it.
>
>Crispin, for the benifit of the lkml readers, can you explain why WireX
>does not want this change?
>
Here's the monster flame-war we had the last time this issue was debated
http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.3/0102.html
My argument against the intent of this change is that no, I do not think
we should restrict LSM modules to be GPL-only. LSM is an API for loading
externally developed packages of software, similar to syscalls. There is
benefit in permitting proprietary modules (you get additional modules
that you would not get otherwise) just as there is benefit in permitting
proprietary applications (you get Oracle, DB2, and WordPerfect).
My argument against the implementation technique of dropping in these
export GPLonly symbols is that my read of the GPL itself means that they
have no legal impact. The crux of the matter is whether a *court* finds
that LSM is "linking" (in the GPL sense) or is an "interface":
* If it is "linking": then all LSM modules end up GPL'd, regardless
of what any of us want.
* If it is "an interface": then the GPL specifically *prohibits* you
from imposing additional restrictions, such as requiring someone
else's module to be GPL'd, to wit:
o Clause 4: "You may not copy, modify, sublicense, or
distribute the Program except as expressly provided under
this License."
o Clause 6: "... You may not impose any further restrictions
on the recipients' exercise of the rights granted herein."
Therefore, the EXPORT_SYMBOL_GPL is just a bunch of useless bloat, with
no legal standing what so ever. If kernel module interfaces are held by
a court to be linking, then export symbols are redundant. If kernel
module interfaces are held by a court to be an interface, then the
export symbols are just wrong.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Note that if this fight ends up being a major issue, I'm just going to
remove LSM and let the security vendors do their own thing. So far
- I have not seen a lot of actual usage of the hooks
- seen a number of people who still worry that the hooks degrade
performance in critical areas
- the worry that people use it for non-GPL'd modules is apparently real,
considering Crispin's reply.
I will re-iterate my stance on the GPL and kernel modules:
There is NOTHING in the kernel license that allows modules to be
non-GPL'd.
The _only_ thing that allows for non-GPL modules is copyright law, and
in particular the "derived work" issue. A vendor who distributes non-GPL
modules is _not_ protected by the module interface per se, and should
feel very confident that they can show in a court of law that the code
is not derived.
The module interface has NEVER been documented or meant to be a GPL
barrier. The COPYING clearly states that the system call layer is such a
barrier, so if you do your work in user land you're not in any way
beholden to the GPL. The module interfaces are not system calls: there
are system calls used to _install_ them, but the actual interfaces are
not.
The original binary-only modules were for things that were pre-existing
works of code, ie drivers and filesystems ported from other operating
systems, which thus could clearly be argued to not be derived works, and
the original limited export table also acted somewhat as a barrier to
show a level of distance.
In short, Crispin: I'm going to apply the patch, and if you as a copyright
holder of that file disagree, I will simply remove all of he LSM code from
the kernel. I think it's very clear that a LSM module is a derived work,
and thus copyright law and the GPL are not in any way unclear about it.
If people think they can avoid the GPL by using function pointers, they
are WRONG. And they have always been wrong.
Linus
On Thu, 17 Oct 2002, Richard B. Johnson wrote:
>
> This, by example, shows that "GPL Only" is unenforceable. I suggest
> that all the "GPL only" zealots try something new (like more good code),
> rather than attempting to prevent honest workers from using code
> they helped develop.
You misunderstand what GPLONLY is all about.
It's not a change to the license. It's a click-through (ie you have to
actually do something specific to make "insmod" even load your license).
Linus
On Thu, 17 Oct 2002, Linus Torvalds wrote:
>
> If people think they can avoid the GPL by using function pointers, they
> are WRONG. And they have always been wrong.
Side note: it should be noted that legally the GPLONLY note is nothing but
a strong hint and has nothing to do with the license (and only matters
for the _enforcement_ of said license). The fact is:
- the kernel copyright requires the GPL for derived works anyway.
- if a company feels confident that they can prove in court that their
module is not a derived work, the GPL doesn't matter _anyway_,
since a copyright license at that point is meaningless and wouldn't
cover the work regardless of whether we say it is GPLONLY or not.
(In other words: for provably non-derived works, whatever kernel
license we choose is totally irrelevant)
So the GPLONLY is really a big red warning flag: "Danger, Will Robinson".
It doesn't have any real legal effect on th emeaning of the license
itself, except in the sense that it's another way to inform users about
the copyright license (think of it as a "click through" issue - GPLONLY
forces you to "click through" the fact that the kernel is under the GPL
and thus derived works have to be too).
Clearly "click through" _has_ been considered a legally meaningful thing,
in that it voids the argument that somebody wasn't aware of the license.
It doesn't change what you can or cannot do, but it has some meaning for
whether it could be wilful infringement or just honest mistake.
Linus
/*
* Since some in the Linux-kernel development group want to play
* lawyer, and require that a GPL License exist for every kernel
* module, we provide the following:
*
* Everything in this file (only) is released under the so-called
* GNU Public License, incorporated herein by reference.
*
* Now, we just link this with any proprietary code and everybody
* but the lawyers are happy.
*/
#ifndef __KERNEL__
#define __KERNEL__
#endif
#ifndef MODULE
#define MODULE
#endif
#include <linux/module.h>
#if defined(MODULE_LICENSE)
MODULE_LICENSE("GPL");
#endif
On Thu, Oct 17, 2002 at 10:08:19AM -0700, Linus Torvalds wrote:
>
> Note that if this fight ends up being a major issue, I'm just going to
> remove LSM and let the security vendors do their own thing. So far
>
> - I have not seen a lot of actual usage of the hooks
The SELinux module uses almost every hook so far. A number of companies
and distros are currently auditing this module, and it will probably be
submitted for inclusion into the main kernel tree after they are
finished.
> - seen a number of people who still worry that the hooks degrade
> performance in critical areas
I have a set of patches to send you today that will solve that problem,
by allowing people who do not want the hook to compile them away into
nothingness. DaveM agrees with the proposed way of doing this.
> - the worry that people use it for non-GPL'd modules is apparently real,
> considering Crispin's reply.
I agree with this, and argue to mark the functions as
EXPORT_SYMBOL_GPL() to make some people feel a bit more warm and fuzzy
that these hooks will not be co-oped for non-GPL use (this includes me.)
In short, I like Christoph's patch.
> I will re-iterate my stance on the GPL and kernel modules:
Thank you for posting this. I know a lot of people appreciate it.
greg k-h
Linus Torvalds wrote:
>Note that if this fight ends up being a major issue, I'm just going to
>remove LSM and let the security vendors do their own thing.
>
If it comes to that, go ahead and apply the patch. I would far rather
have an LSM that requires GPL'd modules than no LSM at all.
> So far
>
> - I have not seen a lot of actual usage of the hooks
>
There are half a dozen modules here http://lsm.immunix.org/lsm_modules.html
I suspect there is a lot more use of LSM pending, and it will appear
when the LSM interface stops changing, and when Linux 2.6 (or 3.0,
whatever) appears. See for example the cover story in the September 2002
Linux Journal: an LSM module being built by Ericsson Research for telco
purposes.
>I will re-iterate my stance on the GPL and kernel modules:
>
> There is NOTHING in the kernel license that allows modules to be
> non-GPL'd.
>
> The _only_ thing that allows for non-GPL modules is copyright law, and
> in particular the "derived work" issue. A vendor who distributes non-GPL
> modules is _not_ protected by the module interface per se, and should
> feel very confident that they can show in a court of law that the code
> is not derived.
>
Thanks for the clarification, but that still leaves questions. In
particular, it is unclear whether a work is "derived" if it includes
kernel header files, which is more or less required if you hope to make
a module fit the interface.
Note that if we decide that #include of a kernel header file means that
a work is derived, then we cause another problem: most Linux
applications come under the GPL. glibc #includes some kernel header
files, and most Linux applications #include glibc headers, so most
applications are #including kernel header files. If #include is the
basis for declaring a module to be a derived work of the kernel, then
there is some bad news coming for people who like to use Oracle and DB2
on Linux ...
Thanks,
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
On Thu, 2002-10-17 at 19:44, Crispin Cowan wrote:
> Note that if we decide that #include of a kernel header file means that
> a work is derived, then we cause another problem: most Linux
> applications come under the GPL. glibc #includes some kernel header
> files, and most Linux applications #include glibc headers, so most
> applications are #including kernel header files. If #include is the
> basis for declaring a module to be a derived work of the kernel, then
> there is some bad news coming for people who like to use Oracle and DB2
> on Linux ...
>
difference is that glibc only uses the glibc-kernheaders; which on
several distros at least are just the data structures and not the
inlines. (and the inlines are in #ifdef KERNEL anyway and removed by the
preprocessor for userspace)
On Thu, 17 Oct 2002, Linus Torvalds wrote:
> (In other words: for provably non-derived works, whatever kernel
> license we choose is totally irrelevant)
one more addition here: as long as those works do not copy any part of the
kernel, be that source code or binary code. Ie. they:
- dont play fancy games binary-patching the kernel or something to that
extent.
There's been a precedent created in the US just two days ago, at the
appelate level, that makes certain types of functionality-enhancing
'binary-patching' practices fall under the copyright of the patched work.
Ie. the GPL qualifies even if the main body of the work in question is not
derived from the kernel, but the work depends on modifying the kernel. So
it's a questionable practice even for non-derived bin-only modules to
patch the kernel or modify it in any not originally intended way.
and the well-known issues of:
- dont use inline functions in headers
- probably even the structure definitions in headers qualify
both can be independently created via the rules of reverse engineering.
(whatever they are in the country it's done - but be prepared for the US
to attempt to take jurisdiction over your acts, wherever you are ...)
Ingo