Like many of us who earn a good living with Linux (for over a decade now) and follow the kernel developer discussions with waxing and waning interest depending on topic, I noticed James Morris' proposal to eliminate the LSM in favor of ordaining SELinux as THE security framework forever and amen, followed by the definitive decision by Linus that LSM would remain.
Well, good, I thought.  Linux should continue to represent freedom for anyone to use basic technology in any way he sees fit.  I turned my attention back to my prosaic day-to-day concerns, thinking that the choice of which security framework to deploy would remain in the hands of the user, regardless of which distributor he chose.
But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks.  Yikes!  Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". 
Since I know that the people behind these security frameworks are serious and worthy folk of general good repute, I've reluctantly come to the tentative conclusion that the fix is in.  There seem to be powers at work that want LSM closed, and they don't want much public discussion about it.
I think this is bad technology.  I've done due diligence by reviewing the LKML discussion behind closing LSM (and there isn't much).  The technical arguments seem to be (1) some people use the LSM interface for "non-security" purposes, which is frowned upon, (2) it's difficult to properly secure a system with an open-ended interface like LSM, and (3) my security framework should be all any fair-minded person would ever want, so we won't let you use something else.
Exactly. 
Well, any system that permits loading code into "ring 0" can't be made completely secure, so argument 2 reduces to argument 3, which is transparently self-serving (and invalid).
I submit for discussion the idea that a free and open operating system should preserve as much freedom for the end user as possible.  To this end, the kernel sho...
[ message continues ]

On Wed, 17 Oct 2007 18:34:16 -0700
I think your statement isn't quite correct: it's not closed to out of

tree security frameworks; it's no longer possible to do MODULES. You

can easily patch any of the ones you mention in (and in fact, this is

how distros that use apparmor will use it anyway). You are totally free

to compile whatever security module you want into your kernel and use

it... I would actually highly encourage that; the freedom to do that is

what Linux is about.
The problem with "loadable security modules" is actually fundamental,

and afaik even the AppArmor people mostly agree with this: The security

any such system provides is generally based on being in a "Safe" state

from the start, so knowing all objects that go through the system, being

able to label them (or at least do something with them, I realize the

term "label" is maybe seen as SELinux specific, but I mean it in a

generic way; the SELinux people will tell you I'm not a fan of their

approach *at all*), check them etc etc. A loadable-module approach can't

do that, it would, at load time, have to inspect the system, make sure

no operations are in "half process" when the LSM hooks go into effect

(just think of it: if you have an operation that gets 3 LSM checks done

to it, and you load and activate your module after the first one is

done as NOP, and your code only sees the 2nd and 3rd... showing that

that gives you sane behavior.... unpleasant no matter what you do) and

on unload, undo all it's work in a semi atomic way (just try doing it

race free is already impossible).
This is the prime motivation behind the change as I understand it: It

wasn't really an option to get this correct, the distros who deploy

these frameworks tend to compile them in anyway as a result, and there
you missed another one: the curent (now merged) patch allows a new

option (which is under development and will be proposed for 2.6.25): A

config option to compile the kernel such that the security framework of

your choice gets com...
[ message continues ]

I make no claims to worthyness, strongly deny being serious,
Nope. I remain carefully neutral regarding the static/dynamic LSM

issue. I was involved with the LSM when SELinux was still known as

the Flask port and my development group proposed the first

implementation, featuring authoritative hooks. Believe me, this
The thing that killed authoritative hooks and that could kill LSM

is the notion (which I refuse to take a side on) that out of tree
I think the primary parties have gotten to the point where they

just call out the arguments by number we've been over them so many
It goes way beyond frowned upon. The first use proposed for LSM was

an audit implementation and that was throughly shredded. Additional
The in-tree vs out-of-tree discussion is independent of LSM.
Casey Schaufler

casey@schaufler-ca.com

-

Indeed. I think there is certainly likely to be some small overlap, but I

*think* they are largely independent issues - "do we want choice in

securitu models" (a very emphatic YES as far as I'm concerned) vs "do we

necessarily want to do them as out-of-tree modules" (I'd like people who

actually *do* things like that to educate us on why and what they are

doing).
Hmm?
		Linus

-