Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[James Morris <jmorris@namei.org>]

On Mon, 17 Apr 2006, Christoph Hellwig wrote:

> > Or, better, remove LSM itself ;)
> 
> Seriously that makes a lot of sense.  All other modules people have come up
> with over the last years are irrelevant and/or broken by design.

It's been nearly a year since I proposed this, and we've not seen any 
appropriate LSM modules submitted in that time.

See
http://thread.gmane.org/gmane.linux.kernel.lsm/1120
http://thread.gmane.org/gmane.linux.kernel.lsm/1088

The only reason I can see to not delete it immediately is to give BSD 
secure levels users a heads-up, although I thought it was already slated 
for removal.  BSD secure levels is fundamentally broken and should 
never have gone into mainline.

How about enough time to get us to 2.6.18, say, two months?


Signed-off-by: James Morris <jmorris@namei.org>

--- linux-2.6.17-rc1.o/Documentation/feature-removal-schedule.txt	2006-04-15 19:57:53.000000000 -0400
+++ linux-2.6.17-rc1.x/Documentation/feature-removal-schedule.txt	2006-04-17 15:18:15.000000000 -0400
@@ -246,3 +246,27 @@ Why:	The interface no longer has any cal
 Who:	Nick Piggin <npiggin@suse.de>
 
 ---------------------------
+
+What:	LSM (Linux Security Modules) including BSD Secure Levels.
+When:	June 2006
+Why:	In the years since LSM was included in the mainline kernel, SELinux
+        has been the only significant module implemented and also included
+        in the mainline kernel.  So we have a generalized framework for
+        one user, SELinux, which itself is a generalized framework.
+        Thus, LSM will be removed, as it adds unecessary infrastructure,
+        performance overhead and complicates the code.  It also attracts
+        a regular stream of misconceived and broken security module
+        submissions to mainline, such as BSD Security Levels, and
+        developers are seeing LSM as the answer to everything rather
+        than really thinking about what they need and how to architect
+        the code properly and generally.  There is also a growing number
+        of proprietary modules hooking into LSM in usafe ways, not 
+        necessarily even for security purposes.  The LSM interface
+        semantics are too weak and such an API does not belong in the
+        mainline kernel.
+        See also, previous discussions on the issue:
+        http://thread.gmane.org/gmane.linux.kernel.lsm/1120
+        http://thread.gmane.org/gmane.linux.kernel.lsm/1088
+Who:	James Morris <jmorris@namei.org>
+
+---------------------------