[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0710010854120.3579@woody.linux-foundation.org>
Date: Mon, 1 Oct 2007 09:04:44 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Stephen Smalley <sds@...ho.nsa.gov>
cc: James Morris <jmorris@...ei.org>,
Andrew Morton <akpm@...ux-foundation.org>,
casey@...aufler-ca.com, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access
Control Kernel
On Mon, 1 Oct 2007, Stephen Smalley wrote:
>
> You argued against pluggable schedulers, right? Why is security
> different?
Schedulers can be objectively tested. There's this thing called
"performance", that can generally be quantified on a load basis.
Yes, you can have crazy ideas in both schedulers and security. Yes, you
can simplify both for a particular load. Yes, you can make mistakes in
both. But the *discussion* on security seems to never get down to real
numbers.
So the difference between them is simple: one is "hard science". The other
one is "people wanking around with their opinions".
If you guys had been able to argue on hard data and be in agreement, LSM
wouldn't have been needed in the first place.
BUT THAT WAS NOT THE CASE.
And perhaps more importantly:
BUT THAT IS *STILL* NOT THE CASE!
Sorry for the shouting, but I'm serious about this.
> Do you really want to encourage people to roll their own security module
> rather than working toward a common security architecture and a single
> balanced solution (which doesn't necessarily mean SELinux, mind you, but
> certainly could draw from parts of it)? As with pluggable schedulers,
> the LSM approach prevents cross pollination and forces users to make
> poor choices.
Another difference is that when it comes to schedulers, I feel like I
actually can make an informed decision. Which means that I'm perfectly
happy to just make that decision, and take the flak that I get for it. And
I do (both decide, and get flak). That's my job.
In contrast, when it comes to security, I see people making IDIOTIC
arguments, and I absolutely *know* that those arguments are pure and utter
crap, and at the same time, I see that those people are supposed to be
"experts".
For example, you security guys still debate "inodes" vs "pathnames", as if
that was an either-or issue.
Quite frankly, I'm not a security person, but I can tell a bad argument
from a good one. And an argument that says "inodes _or_ pathnames" is so
full of shit that it's not even funny. And a person who says that it has
to be one or the other is incompetent.
Yet that is *still* the level of disagreement I see.
So LSM stays in. No ifs, buts, maybes or anything else.
When I see the security people making sane arguments and agreeing on
something, that will change. Quite frankly, I expect hell to freeze over
before that happens, and pigs will be nesting in trees. But hey, I can
hope.
> If Smack is mergeable despite likely being nothing more than a strict
> subset of SELinux (MAC, label-based, should be easily emulated on top of
> SELinux or via fairly simple extension to it to make such emulation
> simpler or more optimal), then what isn't mergeable as a separate
> security module?
I'm simply not interested in this discussion. If you cannot understand the
*meta*discussion above (which has nothing to do with SMACK or SELinux per
se), I cannot help you.
The biggest reason for me to merge SMACK (and AppArmor) would not be those
particular security modules in themselves, but to inject a sense of
reality in people. Right now, I see discussions about removign LSM because
"SELinux is everything". THAT IS A PROBLEM.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists