From: Linus Torvalds <torvalds@linux-foundation.org>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: James Morris <jmorris@namei.org>,
Andrew Morton <akpm@linux-foundation.org>,
casey@schaufler-ca.com, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Mon, 1 Oct 2007 09:04:44 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0710010854120.3579@woody.linux-foundation.org> (raw)
In-Reply-To: <1191253239.7672.76.camel@moss-spartans.epoch.ncsc.mil>
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
next prev parent reply other threads:[~2007-10-01 16:06 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-30 0:20 Casey Schaufler
2007-09-30 8:16 ` Andrew Morton
2007-09-30 8:42 ` Andi Kleen
2007-09-30 17:14 ` Casey Schaufler
2007-09-30 17:34 ` Andi Kleen
2007-09-30 23:24 ` david
2007-09-30 17:29 ` Joshua Brindle
2007-09-30 17:39 ` Andi Kleen
2007-09-30 19:07 ` Theodore Tso
2007-09-30 20:05 ` Andi Kleen
2007-09-30 20:22 ` Theodore Tso
2007-10-01 20:28 ` Casey Schaufler
2007-09-30 20:18 ` Paul Moore
2007-09-30 9:53 ` Christoph Hellwig
2007-09-30 17:19 ` Casey Schaufler
2007-10-02 8:36 ` Thomas Bleher
2007-09-30 17:02 ` Casey Schaufler
2007-09-30 20:30 ` Paul Moore
2007-10-01 11:33 ` James Morris
2007-10-01 15:07 ` Linus Torvalds
2007-10-01 15:40 ` Stephen Smalley
2007-10-01 16:04 ` Linus Torvalds [this message]
2007-10-01 17:54 ` Olivier Galibert
2007-10-02 21:02 ` Bill Davidsen
2007-10-02 21:20 ` Linus Torvalds
2007-10-02 23:25 ` Linus Torvalds
2007-10-03 0:12 ` Alan Cox
2007-10-04 22:56 ` Derek Fawcus
2007-10-04 23:18 ` Chuck Ebbert
2007-10-04 23:44 ` Derek Fawcus
2007-10-03 5:32 ` Crispin Cowan
2007-10-03 3:54 ` Bill Davidsen
2007-10-03 4:52 ` Linus Torvalds
2007-10-05 1:44 ` Eric W. Biederman
2007-10-05 3:04 ` Kyle Moffett
2007-10-05 4:45 ` Eric W. Biederman
2007-10-05 5:48 ` Kyle Moffett
2007-10-05 16:27 ` Casey Schaufler
2007-10-05 18:42 ` Stephen Smalley
2007-10-05 20:08 ` Casey Schaufler
2007-10-05 20:11 ` Eric W. Biederman
2007-10-08 17:50 ` Casey Schaufler
2007-10-08 18:47 ` Eric W. Biederman
2007-10-08 18:53 ` Serge E. Hallyn
2007-10-08 21:05 ` Casey Schaufler
2007-10-08 16:18 ` Serge E. Hallyn
2007-10-08 17:31 ` Casey Schaufler
2007-10-09 13:52 ` Stephen Smalley
2007-10-09 16:02 ` Casey Schaufler
2007-10-08 23:24 ` Bill Davidsen
2007-10-08 16:06 ` Serge E. Hallyn
2007-10-08 17:20 ` Eric W. Biederman
2007-10-08 18:00 ` Serge E. Hallyn
2007-10-08 19:29 ` Eric W. Biederman
2007-10-08 19:50 ` Eric W. Biederman
2007-10-08 20:39 ` Casey Schaufler
2007-10-08 21:02 ` Eric W. Biederman
2007-10-08 21:20 ` Alan Cox
2007-10-10 13:48 ` Eric W. Biederman
2007-10-10 15:45 ` Stephen Smalley
2007-10-10 17:57 ` Casey Schaufler
2007-10-11 10:46 ` Kyle Moffett
2007-10-11 15:41 ` Casey Schaufler
2007-10-11 18:53 ` Kyle Moffett
2007-10-11 20:09 ` Alan Cox
2007-10-08 21:51 ` Crispin Cowan
2007-10-30 4:01 ` Kazuki Omo(Company)
2007-10-30 15:07 ` Casey Schaufler
2007-10-08 20:25 ` Casey Schaufler
2007-10-08 20:57 ` Eric W. Biederman
2007-10-06 19:14 ` Bill Davidsen
2007-10-03 0:10 ` Alan Cox
2007-10-03 0:18 ` Linus Torvalds
2007-10-01 16:39 ` Casey Schaufler
2007-10-01 19:00 ` Theodore Tso
2007-10-01 15:38 ` Casey Schaufler
2007-10-01 20:49 ` Jan Engelhardt
2007-10-01 3:47 ` Serge E. Hallyn
2007-10-01 4:15 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.0.999.0710010854120.3579@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®