From: James Morris
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 4:33 am 2007

On Sun, 30 Sep 2007, Andrew Morton wrote:

> So with the information which I presently have available to me, I'm
> thinking that this should go into 2.6.24.

I think the decision to merge Smack is something that needs to be 
considered in the wider context of overall security architecture.

Smack itself looks fine.  It seems like clean code with interesting ideas, 
and appears to be based upon sound principles.

Merging Smack, however, would lock the kernel into the LSM API.  
Presently, as SELinux is the only in-tree user, LSM can still be removed.

LSM's weak semantics and pervasive deep hooking of the kernel means that 
we'll have to continue dealing with several unpleasant issues, such as the 
abuse of the API by out of tree vendors, with a proliferation of 
binary/proprietary modules which typically maladapt the API for arbitrary 
purposes and/or use dangerous techniques.  We will continue to waste 
resources maintaining this capability for them.

On a broader scale, we'll miss the potential of Linux having a coherent, 
semantically strong security architecture. I have written about this in 
some detail before: http://lwn.net/Articles/240019/

Briefly, SELinux is a security architecture.  It provides an extremely 
high degree of flexibility, in terms of both the types of security models 
implemented, and security policy for those models.  It allows controlled 
composition of different security models, with a common policy language 
framework, allowing the entire system to be analyzed.  The same ideas and 
even code can be reused beyond the kernel as post-DAC security is extended 
into databases, the desktop, distributed applications etc.  It is a 
framework which provides a structured, coherent view of the security of 
the OS (and ultimately, the entire distributed environment).

If LSM remains, security will never be a first class citizen of the 
kernel.  Application developers will see multiple security schemes, and 
either burn themselves trying to support them, or more likely, ignore 
them.
 
Core kernel developers will continue to not have enough information to 
understand what the LSM hooks in their code are supposed to be doing, 
leading to long term maintenance issues and potential security problems.

LSM will remain a magnet for bad ideas.  There's a reason we don't have 
pluggable network stacks, and we are lucky to have had a unified 
networking framework maintained by people who know to say no to things 
like STREAMS and TOE.  I would question whether this quality of 
maintainership would exist if the networking core was simply a bunch of 
deep hooks into which people dumped arbitrary custom stacks.

LSM will prevent us from making systemic improvements to security, as 
there will be no common security architecture.  Things like Netfilter 
would not have been viable with a kernel which simply provided a bunch of 
hooks for networking stacks and an assortment of implementations.

Much of this we have learned from the experience of LSM, and I think it 
has been valuable for that, but I think we need to consider now whether we 
are going to continue down this track in a permanent manner.


- James
-- 
James Morris
<jmorris@namei.org>
-


From: Linus Torvalds
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 8:07 am 2007

On Mon, 1 Oct 2007, James Morris wrote:
> 
> Merging Smack, however, would lock the kernel into the LSM API.  
> Presently, as SELinux is the only in-tree user, LSM can still be removed.

Hell f*cking NO!

You security people are insane. I'm tired of this "only my version is 
correct" crap. The whole and only point of LSM was to get away from that.

And anybody who claims that there is "consensus" on SELinux is just in 
denial.

People are arguing against other peoples security on totally bogus points. 
First it was AppArmor, now this.

I guess I have to merge AppArmor and SMACK just to get this *disease* off 
the table. You're acting like a string theorist, claiming that t here is 
no other viable theory out there. Stop it. It's been going on for too damn 
long.

			Linus
-


From: Stephen Smalley
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 8:40 am 2007

On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote:
> 
> On Mon, 1 Oct 2007, James Morris wrote:
> > 
> > Merging Smack, however, would lock the kernel into the LSM API.  
> > Presently, as SELinux is the only in-tree user, LSM can still be removed.
> 
> Hell f*cking NO!
> 
> You security people are insane. I'm tired of this "only my version is 
> correct" crap. The whole and only point of LSM was to get away from that.
> 
> And anybody who claims that there is "consensus" on SELinux is just in 
> denial.
> 
> People are arguing against other peoples security on totally bogus points. 
> First it was AppArmor, now this.
> 
> I guess I have to merge AppArmor and SMACK just to get this *disease* off 
> the table. You're acting like a string theorist, claiming that t here is 
> no other viable theory out there. Stop it. It's been going on for too damn 
> long.

You argued against pluggable schedulers, right?  Why is security
different?

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.

Some have suggested that security modules are no different than
filesystem implementations, but filesystem implementations at least are
constrained by their need to present a common API and must conform with
and leverage the VFS infrastructure.  Different security modules present
very different interfaces and behaviors from one another and LSM doesn't
provide the same kind of common functionality and well-defined semantics
as the VFS.  The result of merging many wildly different security
modules will be chaos for application developers and users, likely
leading them to ignore everything but the least common denominator.
It almost makes more sense to merge no security modules at all than to
have LSM and many different security modules.

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?

-- 
Stephen Smalley
National Security Agency

-


From: Linus Torvalds
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 9:04 am 2007

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
-

From: Casey Schaufler
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 8:38 am 2007

--- James Morris <jmorris@namei.org> wrote:

> On Sun, 30 Sep 2007, Andrew Morton wrote:
> 
> > So with the information which I presently have available to me, I'm
> > thinking that this should go into 2.6.24.
> 
> I think the decision to merge Smack is something that needs to be 
> considered in the wider context of overall security architecture.

Please recall the reason that we have LSM. It is so that Linus
does not have to listen to the arguments over security architecture.

> Smack itself looks fine.  It seems like clean code with interesting ideas, 
> and appears to be based upon sound principles.

Thank you.

> Merging Smack, however, would lock the kernel into the LSM API.  
> Presently, as SELinux is the only in-tree user, LSM can still be removed.

Ah, the nut of the issue. What follows then is the argument that
SELinux should be the official security architecture of Linux.
I disagree (like you hadn't figured that out) with this position.

> LSM's weak semantics and pervasive deep hooking of the kernel means that 
> we'll have to continue dealing with several unpleasant issues, such as the 
> abuse of the API by out of tree vendors,

Pulling LSM might slow a small set of abusers, but it wouldn't solve the
problem, what with well documented VFS and driver layers available.

> with a proliferation of 
> binary/proprietary modules which typically maladapt the API for arbitrary 
> purposes and/or use dangerous techniques.  We will continue to waste 
> resources maintaining this capability for them.

HeHe. I recall the response to some Tivoli developers when they
made a request not to long ago. I seriously doubt that they feel
the community is putting out much for them.

> On a broader scale, we'll miss the potential of Linux having a coherent, 
> semantically strong security architecture. I have written about this in 
> some detail before: http://lwn.net/Articles/240019/

Here our opinions diverge strongly. My position is that the
security architecture of SELinux is excessive in it's sophistication.
 
> Briefly, SELinux is a security architecture.  It provides an extremely 
> high degree of flexibility, in terms of both the types of security models 
> implemented, and security policy for those models.  It allows controlled 
> composition of different security models, with a common policy language 
> framework, allowing the entire system to be analyzed.  The same ideas and 
> even code can be reused beyond the kernel as post-DAC security is extended 
> into databases, the desktop, distributed applications etc.  It is a 
> framework which provides a structured, coherent view of the security of 
> the OS (and ultimately, the entire distributed environment).

None of which is new or unique to SELinux.

> If LSM remains, security will never be a first class citizen of the 
> kernel.  Application developers will see multiple security schemes, and 
> either burn themselves trying to support them, or more likely, ignore 
> them.

What is the #1 SELinux FAQ?
    "How do I turn it off?"

I'd suggest that application and system developers are perfectly
capable of making rational decisions regarding the security model
that is appropriate to their environments.

> Core kernel developers will continue to not have enough information to 
> understand what the LSM hooks in their code are supposed to be doing, 
> leading to long term maintenance issues and potential security problems.

Is that hypothetical, or do you have examples?

> LSM will remain a magnet for bad ideas.

Thanks a lot.

> There's a reason we don't have 
> pluggable network stacks, and we are lucky to have had a unified 
> networking framework maintained by people who know to say no to things 
> like STREAMS and TOE.  I would question whether this quality of 
> maintainership would exist if the networking core was simply a bunch of 
> deep hooks into which people dumped arbitrary custom stacks.

The counter argument is of course VFS and the driver interface.
I think that the file systems work pretty well. Except for the
flakey ones.

> LSM will prevent us from making systemic improvements to security, as 
> there will be no common security architecture.  Things like Netfilter 
> would not have been viable with a kernel which simply provided a bunch of 
> hooks for networking stacks and an assortment of implementations.

Unless you consider Smack a systemic improvement to security like I do.

> Much of this we have learned from the experience of LSM, and I think it 
> has been valuable for that, but I think we need to consider now whether we 
> are going to continue down this track in a permanent manner.

Why so defensive? SELinux is a fine implementation of Type Enforcement
and if you like that sort of thing I'm all for you using it. Accept that
it may not be for everyone. I certainly don't expect Smack on everyone's
machine.


Casey Schaufler
casey@schaufler-ca.com
-


From: Casey Schaufler
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 9:39 am 2007

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote:
> > 
> > On Mon, 1 Oct 2007, James Morris wrote:
> > > 
> > > Merging Smack, however, would lock the kernel into the LSM API.  
> > > Presently, as SELinux is the only in-tree user, LSM can still be removed.
> > 
> > Hell f*cking NO!
> > 
> > You security people are insane.

I don't know if the field attracts the insane, or if being
in the field drives one there, but I'm not going to deny that
we have our share of high grade loonies.

> > I'm tired of this "only my version is 
> > correct" crap. The whole and only point of LSM was to get away from that.
> > 
> > And anybody who claims that there is "consensus" on SELinux is just in 
> > denial.
> > 
> > People are arguing against other peoples security on totally bogus points. 
> > First it was AppArmor, now this.
> > 
> > I guess I have to merge AppArmor and SMACK just to get this *disease* off 
> > the table. You're acting like a string theorist, claiming that t here is 
> > no other viable theory out there. Stop it. It's been going on for too damn 
> > long.
> 

I'm pulling the whole arguement about when is pluggable good
and when is it bad, as everybody seems inclined to use it to
support thier own position.

> If Smack is mergeable despite likely being nothing more than a strict
> subset of SELinux

Hogwash.

> (MAC, label-based,

Yes.

> should be easily emulated on top of SELinux

Sure, and I can emulate a rubber doorstop with Michealangeo's David,
that doesn't make it a good idea. And I keep seeing "should", not
"is". Emphatic assertion is not evidence.

> or via fairly simple extension to it to make such emulation
> simpler or more optimal),

Making SELinux bigger would not make it suit the typical Smack use
better. Smack is simplified, that's a major point.

> then what isn't mergeable as a separate security module?

Personally, I care about what I produced can do, and the uses to
which it will be put. I am not convinced that SELinux can do many
of the things that Smack can, and I know that a system that can
only be used effectivly by Security Professionals is not for everyone.

Smack has a different focus than SELinux. I see no need for hostility.
If SELinux wants to incorporate Smack features, that's OK with me,
but it won't make SELinux simpler. Heaven knows I have leaned heavily
on the implementation example of SELinux.


Casey Schaufler
casey@schaufler-ca.com
-

From: Theodore Tso
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Oct 1, 12:00 pm 2007

On Mon, Oct 01, 2007 at 11:40:39AM -0400, Stephen Smalley wrote:
> You argued against pluggable schedulers, right?  Why is security
> different?
> 
> 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.

Something should be pluggable, and some things not.  We have multiple
filesystems in the tree; but we only have one scheduler and one TCP/IP
stack.

I'm going to argue that security is more like filesystems than
scheduling.  The real problem with security is that there are no "hard
numbers", as Linus puts it.  Instead, there are different sets of
requirements in terms of what is a valid threat model --- which will
very depending on the environment and how the servers are deployed,
and what the capabilities are of the adversary trying to penetrate
said system --- and how end users are willing to compromise between
security and convenience.  This is much like filesystems, where one of
the reasons why people chose different filesystems is because they
have differing requirements and operational environments, and some
filesystems are better suited for certain requirements and
environments than others.

In some environments, say if you are creating a system that will
handle classified data for the U.S. government, there are formal
requirements that your employer, the NSA, sign off on the solution.
This allows the NSA to force the application programmers and end users
to make the tradeoff tilt very much against convenience in favor of
security.  And given the threat models and capabilities of the
adversaries involved, that's probably appropriate.

But that's not necessarily appropriate for all users.  SELINUX is so
horrible to use, that after wasting a large amount of time enabling it
and then watching all of my applications die a horrible death since
they didn't have the appropriate hand-crafted security policy, caused
me to swear off of it.  For me, given my threat model and how much my
time is worth, life is too short for SELinux.

And I can tell you that certain ISV's, when faced with users
complaining that their commericial application which costs ten times
as much as their Linux distribution doesn't work when SELinux is
enabled, simply tells their customers to disable SELinux.

I've often thought that one of the reasons why SELinux folks argue so
strenuously against AppArmor is because since configuring it to
support new applications is so much easier than SELinux, that on an
even playing ground, in many commercial environments that dwarf the
NSA-mandated security pain of the federal sector, there is fear that
AppArmor would be much more popular with customers than SELinux.  Yes,
AppArmor protects against fewer threats; but if the choice is to go
without SELinux because it's too painful to configure SELinux policy,
surely some protection is better than none.

> Some have suggested that security modules are no different than
> filesystem implementations, but filesystem implementations at least are
> constrained by their need to present a common API and must conform with
> and leverage the VFS infrastructure.  Different security modules present
> very different interfaces and behaviors from one another and LSM doesn't
> provide the same kind of common functionality and well-defined semantics
> as the VFS.  The result of merging many wildly different security
> modules will be chaos for application developers and users, likely
> leading them to ignore everything but the least common denominator.
> It almost makes more sense to merge no security modules at all than to
> have LSM and many different security modules.

Look, the reality is that the common interface for application is
system calls returning EPERM.  If you have to rewrite applications to
use a security module, or force application writers to create a
complicated SELinux policy, application writers will simply balk.  It
Just Won't Happen.  Commercial applications like Oracle, DB2,
Websphere, BEA Application Server, Tivoli Storage Manager, and so on
work on multiple OS's, and not just Linux.  If the application
developers are forced to use a Linux-specific API, most of them will
just walk away; it's much simpler and cheaper to tell users to disable
SELinux.  And in the commercial world, we don't have the "big stick"
the NSA has in the federal/defense space to force application writers
to pay attention to SELinux.

The situation is just the same with filesystems.  The common API is
POSIX.  As filesystem writers, we often kvetch about how limiting
certain filesystem interfaces created 30 years ago might be, but the
reality is, very few applications will use extended interfaces, and so
if we broke readdir() and told application writers that they had to
use this wonderful new read_directory() API that was so much better
than the old readdir() interface, they would laugh at us and ignore
us.  Why do security people think they have the ability to dictate to
application writers that they use specialized API's or write arcane
security policies?

						- Ted
-