In a brief follow up to the earlier pluggable security discussion, Thomas Fricaccia reflected on the implications for the various security frameworks, "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." He then commented on a recent merged patch preventing the loading of security modules into a running kernel, "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'." Linus Torvalds replied:
"Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. So Í don't think this is settled in any way - please keep discussing, and bringing it up. I'm definitely not in the camp that thinks that LSM needs to be 'controlled', but on the other hand, I'm also not going to undo that commit unless there are good real arguments for undoing it (not just theoretical ones).
"For example, I do kind of see the point that a 'real' security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Real usage scenarios with LSM modules, please speak up!"
From: Linus Torvalds <torvalds@...>
Subject: Re: LSM conversion to static interface
Date: Oct 17, 10:18 pm 2007
On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
>
> 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".
Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE
people were ok with it (AppArmor), but I'm with you - I applied it, but
I'm also perfectly willing to unapply it if there actually are valid
out-of-tree users that people push for not merging.
So Í don't think this is settled in any way - please keep discussing, and
bringing it up. I'm definitely not in the camp that thinks that LSM needs
to be "controlled", but on the other hand, I'm also not going to undo that
commit unless there are good real arguments for undoing it (not just
theoretical ones).
For example, I do kind of see the point that a "real" security model might
want to be compiled-in, and not something you override from a module. Of
course, I'm personally trying to not use any modules at all, so I'm just
odd and contrary, so whatever..
Real usage scenarios with LSM modules, please speak up!
Linus
-
From: Arjan van de Ven <arjan@...>
Subject: Re: LSM conversion to static interface
Date: Oct 17, 11:06 pm 2007
On Wed, 17 Oct 2007 18:34:16 -0700
"Thomas Fricaccia" wrote:
>
> 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".
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
are real downsides as well (see below).
> 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.
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 compiled as "exclusive" for your binary kernel, and
such that the code doesn't go via the LSM function pointers anymore, but
just via preprocessor rules, does direct calls instead. (And gets
patched out if you issue kernel commandline options to disable security
entirely). This takes away one of the main performance overheads of LSM
(many many function pointer calls) for those who know which LSM module
they'll be using.
That option obviously doesn't mean that you can't have multiple LSM
drivers anymore in the kernel, again it is an option that IF you know
you'll only use one, you can get rid of all the overhead of needing to
be ready to do multiple.
While this strict technically isn't in conflict with the non-modular
LSM (modular-LSM can obviously be a config option in itself as well),
it does make it a lot easier and cleaner to do things this way.
-
From: Casey Schaufler <casey@...>
Subject: Re: LSM conversion to static interface
Date: Oct 17, 10:03 pm 2007
--- Thomas Fricaccia wrote:
> ...
>
> 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 make no claims to worthyness, strongly deny being serious,
and challenge you to demonstrate my good repute.
> I've reluctantly come to the tentative
> conclusion that the fix is in.
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
is nothing compared to what we went through as a community then.
> There seem to be powers at work that want LSM
> closed, and they don't want much public discussion about it.
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
facilities can use it to avoid the stated intent of the GPL.
> I think this is bad technology. I've done due diligence by reviewing the
> LKML discussion behind closing LSM (and there isn't much).
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
times.
> The technical
> arguments seem to be (1) some people use the LSM interface for "non-security"
> purposes, which is frowned upon,
It goes way beyond frowned upon. The first use proposed for LSM was
an audit implementation and that was throughly shredded. Additional
restrictions on accesses only.
> (2) it's difficult to properly secure a
> system with an open-ended interface like LSM, and
Which is pure feldercarb.
> (3) my security framework
> should be all any fair-minded person would ever want, so we won't let you use
> something else.
That argument makes Linus mad.
> 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 should cleanly permit and support the deployment of ANY security
> framework the end user desires, whether "in-tree" or "out-of-tree". I agree
> that any out-of-tree LSM module should be licensed under the GPL (if for no
> other reason than many current commercial support contracts require
> non-tainted kernels).
>
> But restricting security frameworks to "in-tree" only is bad technology.
>
> "Freedom" includes the power to do bad things to yourself by, for example,
> making poor choices in security frameworks. This possible and permitted end
> result shouldn't be the concern of kernel developers. Making configuration
> and installation of user-chosen frameworks as clean and safe as possible
> should be.
>
> In my opinion.
>
> Though not sure why, I expect to be scorched by this. Try not to patronize
> or condescend. Give me technical arguments backed by real data. Show me why
> a home user or 10,000 node commercial enterprise shouldn't be able to choose
> what he wants for security without having to jump through your hoops. Show
> me why you shouldn't make his use of technology up to him, and as safely and
> conveniently as you can contrive.
The in-tree vs out-of-tree discussion is independent of LSM.
Casey Schaufler
casey@schaufler-ca.com
-
From: Linus Torvalds <torvalds@...>
Subject: Re: LSM conversion to static interface
Date: Oct 17, 10:21 pm 2007
On Wed, 17 Oct 2007, Casey Schaufler wrote:
>
> The in-tree vs out-of-tree discussion is independent of LSM.
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
-
'For example, I do kind of
'For example, I do kind of see the point that a "real" security model might
want to be compiled-in, and not something you override from a module.'
I'm not sure if following Windows principle of restricting system administrator rights (i.e. preventing root from loading any kind of module) is a good way for Linux to follow.
ohh, that troll again...
trasz, you don't have a clue what security frameworks are, do you?
Sure I do. Thing is,
Sure I do. Thing is, restricting root in any way is just a wrong idea. Look how many problems under Windows it causes. The proper way is to not use euid 0.
Besides, under unix restricting root won't work anyway, there are lots of ways to work around that when you have root priviledges - play with /dev/kmem, modify kernel code on disk and reboot etc. That's why current Linux' ppriv model is FUBAR, btw.
Or, an attacker can always
Or, an attacker can always replace a disk or an array in the server, right?
No, you don't have a clue about security frameworks.
I do. I just don't call
I do. I just don't call hacks that attempt to minimize consequences of break-in a framework. Restricting root matters only to these hacks - if attacker does not have root, it won't matter to him if he could load modules as root or not.
trasz = troll
Since when security frameworks are just about root, and loading modules as root?
And if you had a clue, as you say, you would know it's not only to prevent attacks, but also operator errors.
Oh, and modifying kernel modules on disk, rebooting a server, or "playing with /dev/kmem" can be pretty hard, if a user is not allowed to do it, right?
So please, do your basic homework and read about security a bit, troll.
What we have here is a failure to communicate ;->
I know my english is far from being perfect, but I think it's not that hard to understand. I never said security frameworks are just about root. This whole thread, however, _is_ just about root - specifically, it's about preventing root from doing things that would change current security policy, like loading LSM modules.
There are many kinds of operator errors. Unix never tried to do anything to prevent them. If we don't try to prevent root from doing "rm -rf /" (Ok, Solaris does this, FreeBSD does this too, whatever ;-), why should we prevent root from loading modules?
Modyfing kernel modules requires the same permissions as loading modules. That's why I noted that preventing root from loading modules is ineffective anyway - for root, there is always a work around.
rsbac supports loading
rsbac supports loading security modules (as in kernel modules) that are better (technically speaking only of course) than lsm's
however such code will never get in the tree for political reasons mainly (why do you think that some people want selinux as _the_ framework forever ?)
the same thing would have happened with apparmor if they were there first, of course. it's all about control.
SELinux is slow and it is an
SELinux is slow and it is an NSA backdoor. I want PaX and GRsecurity!