From: Casey Schaufler <casey@schaufler-ca.com>

Smack is the Simplified Mandatory Access Control Kernel.

Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other tasks. Smack is a kernel based scheme that requires
an absolute minimum of application support and a very small
amount of configuration data.

Smack is implemented as a clean LSM. It requires no external
code changes and the patch modifies only the Kconfig and Makefile
in the security directory. Smack uses extended attributes and
provides a set of general mount options, borrowing technics used
elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
a pseudo-filesystem smackfs that is used for manipulation of
system Smack attributes.

The patch, patches for ls and sshd, a README, a startup script,
and x86 binaries for ls and sshd are also available on

    http:/www.schaufler-ca.com

The patch has been tested with 2.6.22, 2.6.23-rc8, and
2.6.23-rc8-mm2. Development has been done using Fedora Core 7
in a virtual machine environment and on an old Sony laptop.

Smack provides mandatory access controls based on the label attached
to a task and the label attached to the object it is attempting to
access. Smack labels are deliberately short (1-23 characters) text
strings. Single character labels using special characters are reserved
for system use. The only operation applied to Smack labels is equality
comparison. No wildcards or expressions, regular or otherwise, are
used.

A file always gets the Smack label of the task that created it.

Smack defines and uses these labels:

    "*" - pronounced "star"
    "_" - pronounced "floor"
    "^" - pronounced "hat"
    "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
   is permitted.
3. A read or execute access requested on an object l...
[ message continues ]

Ok, so to control smack label transitions, basically you would
run with CAP_MAC_OVERRIDE (see my note later) so that you're
allowed to change your smack label by writing to
/proc/self/attr/current, then you drop CAP_MAC_OVERRIDE, then you're
no longer able to change your label?  I.e. no inherent label changing
rules through smack itself?

Just making sure I have that right.  If I do, then I think at least
defining the word 'privileged' above, given that this is mac,

Might point out that no other modules must be compiled in along with

Are you sure this isn't something you'd like to really audit?


We're basically inevitably going to be switching to 64-bit caps
"any day now".  Should we just go ahead and do it here?  Now
maybe we should use a less contraversial name than 'mac override'
like 'CAP_MAC_POLICY_ADMIN' :), but I guess CAP_MAC_OVERRIDE
is honest.

(I had started a 64-bit caps patch, but then got stuck trying to
decide whether something needed to be done about
task_capability_lock...)

Well, I guess you wouldn't want to bog down your patch to
that, but would you take your own bit once it was available,
> + *      as published by the Free Softwa

There is work required to audit, SELinux, and LSM that will be
required before Smack or any other module can really use audit
properly. Smack using audit would be nice, but there are already
interesting cases that don't require it. I have fixing up audit
on my todo list, and have made some proposals. It will require

I would be delighted to have a bit of my very own. The granularity
advocates might suggest I use more than one.

Thank you for the comments.


Casey Schaufler
casey@schaufler-ca.com
-

I don't know enough about security even to be dangerous.  I went back and
reviewed the August thread from your version 1 submission and the message I
take away is that the code has been well-received and looks good when
considered on its own merits, but selinux could probably be configured to
do something sufficiently similar.

I'd have trouble declaring that "but" to be a reason to not merge smack.

And that wonderful diffstat really is key to being able to do this.

My major non-technical concern is that Casey Schaufler might get hit by a
bus.  If this happens, we can remove the feature in three minutes (that
diffstat again), but that may not be feasible if people have come to rely
upon the feature.

otoh, if a significant number of people are using smack, presumably someone
else would step up to maintain smack post-bus.  The risk seems acceptable
to me.

My major technical concern is the apparent paucity of documentation.


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

Is smack useful without a patched ls, sshd and init.d?  What is the status
of getting those userspace patches merged?  ie: do you know who to send the
diffs to, and are they likely to take them?

What other userspace tools are likely to need patching?



Notes on the code:


- Please run scripts/checkpatch.pl across the diff.  It generates 50-100
  warnings about minor stylistic matters, and those warnings all look legit
  to me.  (extern decls in C are my fave peeve).

- Smack.txt and the website seem a bit skimpy.  Is there enough
  documentation out there for someone to usefully (and, more importantly,
  safely) start using smack?

- In his review of version 1, Andi suggested that your ruleset traversal
  be protected by RCU.  But it seems that this wasn't done.  Were the races
  which he identified fixed by other means?  If so, what were they?

- hm, netlabels.  Who might be a suitable person to review that code? 
  Seems that ...
[ message continues ]

I bet that the number of people submitting patches / possibly maintaining it
is hyperbelic to the code size. Everyone that runs away from selinux's

As long as one does not need to recompile userspace (like it is the case with
libselinux), it wins.
-

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...
[ message continues ]

Please recall the reason that we have LSM. It is so that Linus


Ah, the nut of the issue. What follows then is the argument that
SELinux should be the official security architecture of Linux.

Pulling LSM might slow a small set of abusers, but it wouldn't solve the

HeHe. I recall the response to some Tivoli developers when they
made a request not to long ago. I seriously doubt that they feel

Here our opinions diverge strongly. My position is that the


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



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


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
-

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
-

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

-

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....
[ message continues ]

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

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



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

Making SELinux bigger would not make it suit the typical Smack use

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
-

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!


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 

I'm simply not interested in this discussion. If you cannot understand the 
*meta*discussion a...
[ message continues ]

And yet you can make the exact same case for schedulers as security, you 
can quantify the behavior, but if your only choice is A it doesn't help 
to know that B is better.

You say "performance" as if it had universal meaning. In truth people 
want to optimize for total tps (servers), or responsiveness on the human 
scale (mail, dns, nntp servers), or perceived smoothness (with many 
threads updating a display to slow with load rather than start visibly 
jumping the motion from one to another), or very short term response 
(-rt patches). People want very different behavior under the same load, 
and that is what *they* call "performance," namely best delivery of 
what's important. The numbers are "hard science" but the choice of which 
numbers are important is still "people wanking around with their opinions".

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-

On Tue, 02 Oct 2007 17:02:13 -0400

To be fair the discussion on security does get down to real set theory
but at that point most people's eyes (mine included) glaze over somewhat.

You can reasonably quantify the behaviour and correctness of a security
model based upon mathematical principles - if anything its *easier* that
schedulers which are so much based on "feeling right".

Smack seems a perfectly good simple LSM module, its clean, its based upon
credible security models and sound theory (unlike AppArmor). I don't see
why it shouldn't go in.

Alan
-

The problem with SELinux isn't the theory. It's the practice. 

IOW, it's too hard to use.

Apparently Ubuntu is giving up on it too, for that reason.

And what some people seem to have trouble admitting is that theory counts 
for nothing, if the practice isn't there.

So quite frankly, the SELinux people would look at whole lot smarter if 
they didn't blather on about "theory".

		Linus
-

You snipped a key part of the argument. Namely:

  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.

which you seem to not have read or understood (neither did apparently 

Blah. Bogus and pointless argument removed.

When it comes to schedulers, "performance" *is* pretty damn well-defined, 
and has effectively universal meaning.

The arguments that "servers" have a different profile than "desktop" is 
pure and utter garbage, and is perpetuated by people who don't know what 
they are talking about. The whole notion of "server" and "desktop" 
scheduling being different is nothing but crap. 

I don't know who came up with it, or why people continue to feed the 
insane ideas. Why do people think that servers don't care about latency? 
Why do people believe that desktop doesn't have multiple processors or 
through-put intensive loads? Why are people continuing this *idiotic* 
scheduler discussion?

Really - not only is the whole "desktop scheduler" argument totally bogus 
to begin with (and only brought up by people who either don't know 
anything about it, or who just want to argue, regardless of whether the 
argumen is valid or not), quite frankly, when you say that it's the "same 
issue" as with security models, you're simply FULL OF SH*T.

The issue with LSM is that security people simply cannot even agree on the 
model. It has nothing to do with performance. It's about management, and 
it's about totally different models. Have you even *looked* at the 
differences between AppArmor and SELinux? Did you look at SMACK? They are 
all done by people who are interested in security, but have totally 
different notions of what "security" even *IS*ALL*ABOUT.

In contrast, anybody who claims that the CPU scheduler doesn't know what 
it's all about is just trip...
[ message continues ]

Actually I had quoted that, made a reply, and decided that my reply was 
too close to a flame and deleted the quote and the nasty reply, because 
I couldn't find a nice way to say what I wanted. Oh well, I tried to 
keep to a higher level, but... on this topic you seem to be off on an 
ego trip. You are not the decider, George Bush is the decider, and the 
only time he's not wrong he didn't understand the question. I checked 
the schedule, it's not you week to be God.

There are sensible people you respect on other topics, who have the 
opinion that there is room for behaviors other than CFS, and who have 
created a pluggable scheduler framework which they are trying to hand 
you on a platter. And you won't even consider that they might be right, 
because you believe there can be one scheduler which is close to optimal 

Unfortunately not so, I've been looking at schedulers since MULTICS, and 
desktops since the 70s (MP/M), and networked servers since I was the 
ARPAnet technical administrator at GE's Corporate R&D Center. And on 
desktops response is (and should be king), while on a server, like nntp 
or mail, I will happily go from 1ms to 10sec for a message to pass 
through the system if only I can pass 30% more messages per hour, 
because in virtually all cases transit time in that range is not an 
issue. Same thing for DNS, LDAP, etc, only smaller time range. If my 

Because people who run servers for a living, and have to live with 
limited hardware capacity realize that latency isn't the only issue to 
be addressed, and that the policy for degradation of latency vs. 

Because people can't get you to understand that one size doesn't fit all 

The real issue is that you can't imagine that people who don't share 
your opinion are not only wrong but don't understand the problem. You 
may be right, but when you say anyone who disagrees is wrong by 
definition, then you have lost sight of productive technical 
differences. When your arguments drop to personal attacks and ra...
[ message continues ]

Bill, that's a *tuning* issue, not a scheduler logic issue.

You can do that today. The scheduler has always had (well, *almost* 
always: I think the really really original one didn't) had tuning knobs.

It in no way excuses any "pluggable scheduler", because IT DOES NOT CHANGE 
THE PROBLEM.

[ Side note: not only doesn't it change the problem, but a good scheduler 
  tunes itself rather naturally for most things. In particular, for things 
  that really are CPU-limited, the scheduler should be able to notice 
  that, and will not aim for latency to the same degree.

  In fact, what is really important is that the scheduler notice that some 
  programs are latency-critical AT THE SAME TIME as other programs sharing 
  that CPU are not, which very much implies that you absolutely MUST NOT 
  have a scheduler that done one or the other: it needs to know about 
  *both* behaviors at the same time.

  IOW, it is very much *not* about multiple different "pluggable modules", 
  because the scheduler must be able to work *across* these kinds of 
  barriers. ]

So for example, with the current scheduler, you can actually set things 
like scheduler latency. Exactly so you can tune things. However, I 
actually would argue that you generally shouldn't need to, and if you 
really do need to, and it's a huge deal for a real load (and not just a 
few percent for a benchmark), we should consider that a scheduler problem.

So your "argument" is nonsense. You're arguing for something else than 
what you _claim_ to be arguing for. What you state that you want actually 
has nothing what-so-ever to do with pluggable schedulers, quite the 
reverse!

It's also totally incorrect to state that this is somehow intrisicly a 
feature of a "server load". Many server loads have very real latency 
constraints. No, not the traditional UNIX loads of SMPT and NNTP, but in 
many loads the latency guarantees are a rather important part of it, and 
you'll have benchmarks that literally test how high the l...
[ message continues ]

Sounds good.

I want to inject some fresh ideas into this discussion from a completely
different viewpoint, who knows I might get lucky and make things
better.

All you can do with the LSM is return -EPERM when the normal unix
permissions would not have allowed an operation.  I don't see where
there is any magic or mystery in that, or any need for deep
understanding.


What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.


SElinux is not all encompassing or it is generally incomprehensible I
don't know which.  Or someone long ago would have said a better
way to implement containers was with a selinux ruleset, here is a
selinux ruleset that does that.  Although it is completely possible to
implement all of the isolation with the existing LSM hooks as Serge
showed.

It is a legitimate criticism of the LSM that we are not improving our
in-kernel abstractions to allow better concepts to base decisions
upon when to return -EPERM.  My first dealing with selinux and the lsm
was when I fixed a security issue in /proc fixed the abstractions we
were using and the default selinux security policy had a fit.  If
don't have good concepts in /proc/pid/xxx which is heavily used it
would not surprise me at all if there are lots of other places in the
kernel where our abstractions holes that have not yet been shorn up.

We also have in the kernel another parallel security mechanism (for
what is generally a different class of operations) that has been quite
successful, and different groups get along quite well, and ordinary
mortals can understand it.   The linux firewalling code.


The linux firewalling codes has hooks all throughout the networking
stack, just like the LSM has hooks all throughout the rest of linux
kernel.  There is a difference however.  The linux firewalling code in
addition to hooks has tables behind those hooks that it consults.
There is generic code to walk those tables and consult with different
k...
[ message continues ]

This sort of depends on perspective; typically with security  
infrastructure you actually want "... the ability to return success  
when we can clearly articulate that we want to *ALLOW* something".   
File permissions work this way; we don't have a list of forbidden  
users attached to each file, we have an owner, a group, and a mode  
representing positive permissions.  With that said in certain high- 
risk environments you need something even stronger that cannot be  

The difference between SELinux and containers is that SELinux (and  
LSM as a whole) returns -EPERM to operations outside the scope of the  
subject, whereas containers return -ENOENT (because it's not even in  

Well, I wouldn't go so far as the "ordinary mortals can understand  

This is almost *EXACTLY* what SELinux provides as an LSM module.  The  
one difference is that with SELinux some compromises and restrictions  
have been made so that (theoretically) the resulting policy can be  
exhaustively analyzed to *prove* what it allows and disallows.  It  
may be that SELinux should be split into 2 parts, one that provides  
the underlying table-matching and the other that uses it to provide  
the provability guarantees.  Here's a direct comparison:

netfilter:
   (A) Each packet has src, dst, port, etc that can be matched
   (B) Table of rules applied sequentially (MATCH => ACTION)
   (C) Rules may alter the properties of packets as they are routed/ 
bridged/etc

selinux:
   (A) Each object has user, role, and type that can be matched
   (B) Table of rules searched by object parameters (MATCH => allow/ 
auditallow/transition)
   (C) Rules may alter the properties of objects through transition  
rules.

If there are areas where people are confused about SELinux, think it  
may be improved, etc, we would be *GLAD* to hear it.  I'm currently  
struggling to find the time between a hundred other things to finish  
a script I offered to Casey Schaufler a month and a half ago which  

Actually the on...
[ message continues ]

Other than ACLs, of course, which do allow blacklisting individual users.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-

Yes.  However last I looked at the LSM hooks we first do the normal unix
permission checks.  Then we run the hook.  So it can only increase the

Yes.  However if you look at what the first implementations were.  Especially
something like linux-vserver.  All they provided was isolation.  So perhaps
you would not see every process ps but they all had unique pid values.

I'm pretty certain Serge at least prototyped a simplified version
of that using the LSM hooks.  Is there something I'm not remember in
those hooks that allows hiding of information like processes?

Yes. Currently with containers we are taking that one step farther as

True.  Probably a more accurate statement is:`unix command line power
users can and do handle it after reading the docs.  That's not quite
ordinary mortals but it feels like it some days.  It might all be

Ok.  There is something here.

However in a generic setup, at least role would be an extended match
criteria provided by the selinux module.  It would not be a core
attribute.  It would need to depend on some extra functionality being

How about thinking of it another way.  

Perform the split up you talked about above and move the table
matching into the LSM hooks.

Use something like the iptables action and match to module mapping
code so we can have multiple modules compiled in and useable at the
same time with the LSM hooks.

I think it is firmly established that selling SElinux to everyone is
politically untenable.  However enhancing the LSM (even if it is
mostly selinux code movement down a layer) I think can be sold.

If I could run Serge's isolation code and selinux rules at the same
time that would be interesting. 

My impression is that selinux is one monolithic blob that doesn't
allow me to incrementally add matching or action features that I
find interesting.

Eric
-

But given that namespaces are making it upstream, what else is to be
gained from the bsdail module?  What exactly are you looking for?

1. are you looking to cover all the corner cases - i.e. prevent killing
a process in another namespace through F_SETOWN or mqueue, etc?

2. are you looking for a potentially easier fix to the current absence
of isolation in the user namespace?

3. are you just generally looking to make lsm/selinux easier for
yourself to configure?

If 1, an selinux policy should cover you.  So you can then skip to 3.
Or, alternatively, I do plan - as soon as my free time clears up a bit -
on demonstrating how to write some selinux policy to create a secure
container based on current -mm + your experimental network namespace
patches.

If 2, well, see 1.  But for the long term solution, I don't think we
want that in an LSM.  Rather we want to implement proper user namespace
enforcement in the kernel, then put 'policy' basically at the filesystem
layer and further in userspace.  So maybe not exactly what I've outlined
before, but certainly similar.  The filesystem can decide what user
namespace a file belongs to, whether based on cryptographic keys stored
with the file, or based on mount arguments, or something else.  Users
can get access to those files using keys stored with their task_struct
if they are not in the right user namespace to otherwise access it.
Otherwise access to a file in another user namespace defaults to
the 3d mode bit, so you default to being 'other'.  Further isolation
probably still belongs in selinux or another lsm.

If 3, then selinux policy modules may actually help you, else either
a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
selinux policy, emulating the iptables rules formats, may be what you

Actually with policy modules it gets much much better.  I have in fact
been able to pretty easily write a short policy module to, say, create
an selinux user which ran as root and had full access to the system t...
[ message continues ]

Good question.  I keep tripping over the LSM hooks, and I have the
distinct impression that part of the current contention and lack of
agreement is simply the way things are current factored.  So I'm
putting for a constructive suggestion that has the possibility of

I'm looking towards this yes.  There are times when we deliberately
allow mixing of things by the definition of what namespaces are and

No.  I'm not even worrying about the user namespace until it resembles
complete.  Currently I just view it as a stub because as is, the
security namespace is pretty much useless for any case I think about.
We still have way to many cases where the kernel treats different

Well.  I'm trying to make the LSM more useful to hack on and configure,
and much less contentions for ordinary people to use.

There is one issue with sockets that has come up where there are
people who really want to filter things at connect and bind time.
The LSM is so inflexible the only sane suggestion at the time was
to duplicate the LSM hooks and add an new iptable style table
for making that decision.

Also I'm thinking towards what do we have to do isolate the security
module stuff in the context of a namespace.  So that a person in
a container can setup their own rules that further restrict the
system.

So far I'm not ready to do anything yet but I'm keeping a weather eye


I don't want to have to choose my LSM at compile time.  I want to
add support into the kernel at compile time and be able to configure
it before I go multi-user.  I know this kind of architecture is
achievable because iptables allows it.

When I conceive as the security modules as just a firewall between
applications on my own box I think, oh yeah this is no big deal,
I might want to limit something that way some time.  These are just
some additional rules on when to return -EPERM.  So I ask myself why
is this situation much less flexible and much harder to use then our

Ok. Interesting.  Are these kernel modules?

Still while...
[ message continues ]

I honestly think that the barrier has been more political
in nature than technical. I don't know how long you've been
watching, but no attempt to get an LSM upstream has escaped
exagerated cricism from certain factions. Only someone who wants
to get cut to metaphorical ribbons would submit a little LSM.
Maybe that will get better now. I sure hope so.


Casey Schaufler
casey@schaufler-ca.com
-

Yes.  Me to.  I certainly agree about the political part.

My only hope was to suggest something that my reduce what there is to
get political about.

Eric
-

In the selinux example I plan to do set up soon, that will be done
using the '.' namespace separator.

Every object/subject in vserver1 will have a type 'vserver1.whatever'.
'vserver1.root_t', 'vserver1.etc_t', etc.

I don't know how far the policy tools have gotten, but they are
*supposed* to implement constraints at policy compile time such that
every type which is a child of 'vserver1' would have no more access than
what is granted to type 'vserver1'.  So this provides a pretty nice
conceptual way to set up security for a vserver.

Then using the userspace policy server and metapolicy (this would be a
step or two beyond my first example) the policy could define rules about
what sort of policy could be added by a process of type
'vserver1.root_t'.  So we can allow the container admin to introduce
policy changes affecting only his own container, and subject to all

It actually used to be far more flexible than it is now.  The consensus
appears to be that it's just too hard - at times impossible - to
properly label every object or subject at some point after they've all
been created (processes created, inodes read from disk, etc).  Two
examples:

	1. you've got pid 777.  How was it created?  Can you trust it's
	history?  In my DTE module I solved this by keeping track of the
	*full* invocation history until a policy was loaded.  I think
	tomoyo may do something similar.  But it's really not
	sufficient, especially since you don't even want a LSM loaded
	at all.  So you can't reduce it to 'boot_t executd init_t
	executed login_t executed shell_t', you have to keep track of
	every inode executed

	2. how do you reliably re-evaluate, for some file, what label
	to assign to it?  Do you guess at a pathname?  Do you trust that
	the inodes have been pre-labeled for every LSM, so when you load
	the LSM you can grab the xattrs?

So it's a valid question - do we address these sorts of concerns in
order to add flexibility, or do we keep things as simple as possible
and say that it's...
[ message continues ]

Dear, Folks,

Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)

When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.

Sincerely,

OMO



-- 
Kazuki Omo: k-omo@sios.com
Group Manager, OSS Technology Center
Diary: http://omok.livejournal.com
-

Most excellent. Thank you.


Casey Schaufler
casey@schaufler-ca.com
-

To be very clear.  Enhancing the LSM is of interest to me as it looks
like that is a way to get people working and playing well together,
and that ultimately to be able to run a full distro in a container
I'm going to need this ability.

Examples of better ways to do this in selinux, LIDS, or SMACK are only
interesting as far as they suggest how to enhance the LSM.

I honestly think enhancing the LSM would actually reduce it's ability
to be abused, because nothing would directly own the hook.

My very practical question:  How do I run selinux in one container,
and SMACK in another?

Eric
-

In AppArmor, we plan to 'containerize' (not sure what to call it) policy
so that you can have an AppArmor policy per container. This is not
currently the case, it is just the direction we want to go. We think it
would be very useful for virtual hosts to be able to have their own
AppArmor policy, independent of what other hosts are doing.

The major step towards this goal so far is that AppArmor rules are now
canonicalized to the name space.

However, I have never considered the idea of separate LSM modules per
container. The idea doesn't really make sense to me. It is kind of like
asking for private device drivers, or even a private kernel, per name
space. If that's what you want, use virtualization like KVM, Xen, or VMware.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

-

In the LSM model you don't because you could have the same container
objects visible in different contains at the same time and subject to
different LSMs. What does it mean to pass an SELinux protected object
over an AppArmour protected unix domain socket into a SMACK protected
container ?

If you want consistency then you probably need to put the container id
into the LSM calls and provide the ability in one system to do container
specific checks. Right now I suspect the way to do it is to complete the
work to convert SMACK rulesets into SELinux rulesets with tools.

Really its the same problem as "I'd like to use different file permission
systems on different process identifiers" and it would be very hard to
get right simply because objects can pass between two different security
models.

Pyramid tried to do the "simple" case of BSD and System 5 on the same box
and got caught out even with that because of the different rules on stuff
like chgrp..
-

You raise a good point.  My intuitive definition would go something like
this.  In the initial LSM space we would have whatever is the primary
LSM and it would always be invoked about everything.   However it
would view a single container (no matter what user in that container)
as having a single set of permissions.  Then the LSM in the container
be asked to further validate accesses, but it would distinguish
between users in the container.

At this point it looks like if I am going to be effective at doing
anything I am going to need to step back watch SMACK get merged and
then really look at what the LSM modules are implementing.  Then
I can refactor the whole mess and move additional functionality into

Yep.  Although the isolation of a container with a completely
different set of namespaces is tight enough that except for people
debugging a container from processes in the container from outside the
container object exchange essentially doesn't happen.

You do raise a very good question here.  Does an LSM implement a
different file permission system?  Or does an LSM implement a firewall
between processes?

Certainly selinux seems too programmable to be considered just a

Yes.  There are many hard problems here and many people have tried and
failed in the past.  That hasn't stopped me before, and I don't see
why security should be any different.

Eric
-

SELinux internally has a notion of a type hierarchy, where a type is
limited to a subset of its parent's permissions, and one can then
delegate the ability to manage sub-types via a policy daemon.  But this
is all handled in userspace; the kernel doesn't care about it.

Ditto for the modular policy support - that's a userspace construct that
is ultimately turned into a single coherent policy for the kernel to

A LSM implements a security model, where that model may encompass all
processes and objects.  SELinux (and Smack) in particular implement
mandatory access control and thus need to enforce consistent policy over
all processes and objects based on their security labels.

-- 
Stephen Smalley
National Security Agency

-

I think that you'll want to be careful with that approach.
Smack and SELinux both implement mandatory access control,
with very different mindsets too be sure, but MAC nonetheless.
Smack doesn't use any LSM hooks that SELinux doesn't. You
aren't going to get a very broad view of potential LSMs
comparing these two. AppArmor and TOMOYO are much more likely
to provide interesting alternative viewpoints. If you want to

What he said as far as Smack and SELinux go. Other models need not
encompass all processes and objects.


Casey Schaufler
casey@schaufler-ca.com
-

Ok, finally getting some time to work on this stuff once again (life  
gets really crazy sometimes).  I would like to postulate that you can  
restate any SMACK policy as a functionally equivalent SELinux policy  
(with a few slight technical differences, see below).  I've been  
working on a script to do this but keep getting stuck tracking down  
minor bugs and then get dragged off on other things I need to do.   
Here is the method I am presently trying to implement:

First divide the SELinux access vectors into 7 groups based on which  
ones SMACK wishes to influence:
	(R) Requires "read" permissions (the 'r' bit)
	(W) Requires "write" permissions (the 'w' bit)
	(X) Requires "execute" permissions (the 'x' bit)
	(A) Requires "append" OR "write" permissions (the 'a' bit)
	(P) Requires CAP_MAC_OVERRIDE
	(K) May not be performed by a non-CAP_MAC_OVERRIDE process on a  
CAP_MAC_OVERRIDE process
	(N) Does not require any special permissions

The letters in front indicate the names I will use in the rest of  
this document to describe the sets of access vectors.

Next define a single SELinux user "smack", and two independent roles,  
"priv" and "unpriv".  We create the set of SMACK equivalence-classes  
defined as various SELinux types with substitutions for "*", "^",  
"_", and "?", and then completely omit the MLS portions of the  
SELinux policy.

The next step is to establish the fundamental constraints of the  
policy.  To prevent processes from gaining CAP_MAC_OVERRIDE we  
iterate over the access vectors in (K) and add the following  
constraint for each vector:
	constrain $OBJECT_CLASS $ACCESS_VECTOR ((r1 == r2) || (r1 == priv))

This also includes:
	constrain process transition ((r1 == r2) || (r1 == priv))

Then we require privilege to access the (P) vectors; for each vector  
in (P) we add a constraint:
	constrain $OBJECT_CLASS $ACCESS_VECTOR (r1 == priv)

At this point the only rules left to add are the between-type rules.   
Here it gets mildly complicated becaus...
[ message continues ]

I'm still waiting to see the proposed SELinux policy that does
what Smack does. I can accept that you don't see anything that
can't be implemented thus, but that's not the point. You've
provided some really clear design notes, and that's great, but
it ain't the code. You said that you could write a 500 line
perl script that would do the whole thing, and that left some
people with an impression that Smack is a subset of SELinux.
Well, I'm already finding myself digging out from under that
missunderstanding, and with people who are assuming that your
policy has been done, "proving" the point.

I see nothing wrong with your approach, although I'm curious
about how your emulation of capabilities will work, or if it's
even rational to include in the SELinux context. I have my
benchmark lab* ready to go when you have a policy for me to try.

Thank you.

----
* It's a sony VAIO laptop with an 800MHZ AMD processor.


Casey Schaufler
casey@schaufler-ca.com
-

That *is* the SELinux policy which does what Smack does.  I keep  
having bugs in the perl-script I'm writing on account of not having  
the time to really get around to fixing it, but that is exactly the  

I'd love to have time to finish the script but unfortunately real  
life keeps interfering and I'm going to have to go back to lurking on  
this thread.

Cheers,
Kyle Moffett

-

How about posting the partial one you've got ?
-

How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP
in another? How would you run SMP in one and UP in the other?
One aspect that SELinux and Smack share is that they only really
provide security if all processes involved are under their control,
just like the preemption behavior.

This is not necessarily true of all possible LSMs. In that case it may
be practicle to have different behavior for different containers.


Casey Schaufler
casey@schaufler-ca.com
-

Well the style of kernel preemption is generally an implementation

Right.  But in a container that look like a full system arguably this
is doable.  There are a few additional details that would be needed
to ensure containers are isolated from each other that would be

When we get to the point where this is a real concern I believe the
isolation will be sufficient that this it is a valid question to
ask.

If there is nothing visible to user space I don't care.  But security
modules are fundamentally about changing when -EPERM happens so are
very visible to user space.

Eric
-

I want what we have for the rest of the kernel.  The ability to build
one kernel binary that can do everything and that is configured at
boot time or run time.

My perspective is that if we are going to have an in-kernel labeling
operation running that may be an unconditional function that can
only be enabled or disabled as the system runs.

I'm not after the kind of flexibility that allows us to do things late
in the game, at least not inherently.  I'm after things like being
able to have the checks separated from the labeling, roughly where
are today with iptables.

I'm really after refactoring the problem so that we don't get these
winner take all fights for use of the LSM.  If we can break things
up into small enough factors so that a solution does not all come
from one project then I think we have a chance of getting multiple
security module authors to work together.  Right now we don't seem
to have that kind of cross pollination when using the LSM.

But frankly even the ability to compile in all of the kernel security
modules at compile time and be able to switch between them with a

My perspective of the stacker module was that it's problem was it
did not change the problem into a more useable form.  That it didn't
dig deep enough to have useful consequences.  I don't think the goal
was bad.

In one sense what I'm proposing is putting the stacker functionality
into the LSM.  Allowing me to choose after I boot my kernel which of
the compiled in security modules I want to run, and ideally for each
logical kind of security test which order I call the security modules

Communication error.  I can't do small pieces that are useful in an
upstreamable fashion.  That is the problem I see.  I don't care about
out of kernel code.  If we have to compile all of the code into the
kernel and have no exports to modules that is fine with me.

My question is how do we get more interesting functionality into the
kernel.  How do we get the generic kernel support simple and easy to
ha...
[ message continues ]

IMHO, containers have a subtly different purpose from LSM even though  
both are about information hiding.  Basically a container is  
information hiding primarily for administrative reasons; either as a  
convenience to help prevent errors or as a way of describing  
administrative boundaries.  For example, even in an environment where  
all sysadmins are trusted employees, a few head-honcho sysadmins  
would get root container access, and all others would get access to  
specific containers as a way of preventing "oops" errors.  Basically  
a container is about "full access inside this box and no access  
outside".

By contrast, LSM is more strictly about providing *limited* access to  
resources.  For an accounting business all client records would  
grouped and associated together, however those which have passed this  
year's review are read-only except by specific staff and others may  
have information restricted to some subset of the employees.

So containers are exclusive subsets of "the system" while LSM should  

I have seen more *wrong* iptables firewalls than I've seen correct  
ones.  Securing TCP/IP traffic properly requires either a lot of  
training/experience or a good out-of-the-box system like Shorewall  
which structures the necessary restrictions for you based on an  
abstract description of the desired functionality.  For instance what  
percentage of admins do you think could correctly set up their  
netfilter firewalls to log christmas-tree packets, smurfs, etc  
without the help of some external tool?  Hell, I don't trust myself  
to reliably do it without a lot of reading of docs and testing, and  
I've been doing netfilter firewalls for a while.

The bottom line is that with iptables it is *CRITICAL* to have a good  
set of interface tools to take the users' "My system is set up  
like..." description in some form and turn it into the necessary set  
of efficient security rules.  The *exact* same issue applies to  
SELinux, with 2 major additional pr...
[ message continues ]

Good suggestion. In fact, that is exactly how I approached my
first two attempts at the problem. What you get if you take that
route is an imposing infrastructure that has virually nothing
to do and that adds no value to the solution. Programming to the
LSM interface, on the other hand, allowed me to drastically reduce

But Kyle, it's already possible to compile out the part I don't
want. I configure SELinux off and away I go.

Smack is not a subset of SELinux, it behaves differently. SELinux
has a policy that is program behavior oriented, Smack is strictly
subjet/object oriented. Your 4 components (A-D) are meaningless to

The granularity and consequently the size of the policy specificiation
result in policies that are too complicated. Tieing the policy to the
expected behavior of specific applications adds to the complexity.
SELinux is designed to increase in complexity as it evolves. Making

Now what kind of tools are you talking about? Static analysis?

That would be silly. Smack uses a significantly smaller set of hooks
than SELinux requires and still does interesting things. We went through
the "replace LSM with the SELinux interface" exercise a couple years


Casey Schaufler
casey@schaufler-ca.com
-

(tongue-in-cheek)

No no, everyone knows you don't build simpler things on top of more
complicated ones, you go the other way around.  So what he was

-serge
-

Having gone from proposing a simpler and easier to use security system 
as an alternative to SELinux, you now propose to change the one working 
security system we have. And yes, it's hard to use, but it works. Let's 
keep this a patch, people who want adventure can have one, and people 
who have gotten Linux accepted "if SELinux is enabled" will avoid one.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

-

I'm not sure how seriously anyone ought to take what I'm about to
outline. Please feel free to treat it with as much or as little
reverence as you choose.

How to implement SELinux starting from Smack.

You'll need to break up the current rwxa accesses into a set
that matches the current SELinux set. Assign each a letter and
a "MAY_ACTION" #define.

You'll need a mapping for domain transitions, something like:

     subject-label program-label new-subject-label

This will require bprm hooks that aren't there now.

Additional hooks will need to be filled out as Smack does not
add access control to things that aren't objects or actions that
aren't accesses. Treat these as if they are accesses to objects
and there shouldn't be too much trouble.

Do something about the linear search for subject/object label pairs.
With the larger label set searching will become an issue.

Audit integration, too. The networking code will require some work
for ipsec. The interfaces are pretty clean, Smack isn't using it
because the CIPSO interface is simpler, not because there's any
real problem with it.

I wouldn't expect the whole thing to be more than a couple week's
work for someone who really wanted to do it.


Casey Schaufler
casey@schaufler-ca.com
-