[PATCH] make LSM register functions GPLonly exports

[PATCH] make LSM register functions GPLonly exports

[Christoph Hellwig]

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);

Re: [PATCH] make LSM register functions GPLonly exports

[Greg KH]

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

Re: [PATCH] make LSM register functions GPLonly exports

[Christoph Hellwig]

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.

Re: [PATCH] make LSM register functions GPLonly exports

[Jeff Garzik]

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

Re: [PATCH] make LSM register functions GPLonly exports

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] make LSM register functions GPLonly exports

[Christoph Hellwig]

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.

Re: [PATCH] make LSM register functions GPLonly exports

[Linus Torvalds]

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

Re: [PATCH] make LSM register functions GPLonly exports

[Greg KH]

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

Re: [PATCH] make LSM register functions GPLonly exports

[Linus Torvalds]

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

Re: [PATCH] make LSM register functions GPLonly exports

[Ingo Molnar]

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

Re: [PATCH] make LSM register functions GPLonly exports

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] make LSM register functions GPLonly exports

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

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)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] make LSM register functions GPLonly exports

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1840 bytes --]

On Thu, 17 Oct 2002, Christoph Hellwig wrote:

> 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.

There is no way of preventing authors from using "your" code once
you publish it. They just can't claim that they wrote it without
violating copyright law. Copyrights and Licensing are two different
independent things. See a Lawyer.

The attached 'C' program, when linked with any proprietary module,
will bypass all the  "EXPORT_GPL_ONLY" and similar "SCREW_YOU" macros.
To prevent using this or other similar work-arounds to road-blocks
thrown in the way of users, you would have to get GNU 'ld' to prevent
partial linking and make sure that all old copies have been destroyed.

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.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 601 bytes --]

/*
 *   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

Re: [PATCH] make LSM register functions GPLonly exports

[Linus Torvalds]

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