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,

quoted text
> + *      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

-

Note that Serge said "SELinux re-written on top of Smack", not "rewrite

Smack to be more like SELinux".  I don't believe the former is even

possible, given that Smack is strictly less expressive and granular by

design.  Rewriting Smack to be more like SELinux should be possible, but

seems like more work than emulating Smack on SELinux via policy, and to

what end?
--

Stephen Smalley

National Security Agency
-

Y'all keep saying that, but since noone has actually done that

SELinux policy, or anything like it, I maintain that it's not as

easy as you are inclined to claim. It is certainly not the "I'll
Well, there is that. I personally think that one implementation of

SELinux is plenty.
On the other hand, I think that if the concept of a single security

architecture has value the advocates of that position ought to be

looking at SELinux on/of Smack just as carefully as they look at

Smack on/of SELinux. If they are not, I suggest that the Single

Security Architecture argument is a sophistic device rather than

a legitimate issue of technology and should thus be ignored.
Casey Schaufler

casey@schaufler-ca.com

-

It would be interesting to see the result of those first two attempts

(even if they didn't get very far) just to see your approach and what
To clarify, SELinux is also based on subjects and objects grouped into

equivalence classes (labels), and the granularity at which one applies

protection is configurable, so you can certainly have very

coarse-grained labels that don't require any specific knowledge of

application behavior.  A type is just a security equivalence class - it

doesn't have to map to an application at all.
Also, the idea behind SELinux was that its policy engine (security

server, security/selinux/ss/*) could be replaced with other

implementations without affecting the rest of SELinux if someone wanted

to try radically different logic.  The interface to that policy engine
Well, it reveals the complexity already present in the system, and gives

you the option of controlling it.  Your choice as to at what granularity
I don't think Eric is proposing replacing LSM with the SELinux interface

as it exists today, but rather making LSM more Netfilter-like and

radically refactoring SELinux (and any other security module) to consist

of a chain of smaller modules that are more general and reusable, and

that can be composed and applied in interesting ways via an

iptables-like interface.  I'm not sure what that would look like

exactly, but it seems reasonable to explore.
One of the things left unresolved with LSM is userland API, and it does

involve more than just returning EPERM or EACCES to applications.  You

already have patched ls and sshd programs, and have acknowledged the

need for more userland modifications to ultimately achieve your own

goals.  If LSM is going to succeed in the kernel, then ultimately you

need some common API for userland so that you don't need separate

versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.
--

Stephen Smalley

National Security Agency
-

Yes.  Simple isolation is a different and simpler problem that can be

solved with the LSM hooks today.  I brought it up for the contrast in

what the LSM hooks can be useful for.  Hopefully allowing the LSM

hooks to be perceived as something other then just hacks for selinux.
Using a security module for isolation is currently uninteresting

because it would preclude use of a security module like selinux or

smack, because we can have at most one security module at a time

loaded.
I have seen several other places where a custom LSM would have

been a good solution but because we don't allow composition solving

a little problem with the LSm is not interesting enough to allow

the code to be merged.
So I see the current structure of the LSM hooks as hindering
Exactly refactoring security modules into small simple reusable chunks

to allow reuse.  It might look something like selinux chains or it

might not.  Inherently it needs to expose what you can do at the

existing hook points, and it needs to allow usage by different modules

that are compiled in at the same time.
It is certainly the case that you would not need to use all of the
Likely.  Until we have a generalized LSM interface with 1000 config

options like netfilter I don't expect we will have grounds to talk

or agree to a common user space interface.  Although I could be

wrong.
Eric

-

Gulp. I know that many of you are granularity advocates, but I

have to say that security derived by tweeking 1000 knobs so that

they are all just right seems a little far fetched to me. I see

it as poopooing the 3rd and most important part of the reference

monitor concept, "small enough to analyze". Sure, you can analyse

the 1000 individual checks, but you'll never be able to describe

the system behavior as a whole.
Casey Schaufler

casey@schaufler-ca.com

-

Agreed.  I wasn't thinking 1000 individual checks but 1000 different

capabilities, could be either checks or actions, basically fundamental

different capabilities.  Things like CIPSO, or the ability to store a

security label on a file.  I would not expect most security policies

to use most of them.  Neither do I expect Orange book security to

necessarily be what people want to achieve with the LSM.   But I

haven't looked at it enough detail to know how things should be

factored, in this case I was simply extrapolating from the iptables

experience where  we do have a very large number of options.
The real point being is that I would be surprised if we could come

to an agreement of a common user space API when we can't agree on how

to compile all of the security modules into the kernel and have them

play nice with each other. 
Assuming we can achieve security modules playing nice with each other

using a mechanism similar to iptables, then what needs to be evaluated

is the specific table configuration we are using on the system, not

the full general set of possibilities.  Further I expect that for the

truly security paranoid we want the option to disable further table

changes after the tables have been configured.
On another side personally I don't see where the idea comes from that

you can describe system behavior as a whole without analyzing the

entire kernel.  Has there been work on a sparse like tool that I'm

not aware of to ensure the we always perform the appropriate security

checks on the user/kernel interface boundary?
Eric

-

You start getting into some pretty serious mindset battles on

this particular road. For starters, the "hooks" have to be

authoritative if you want them properly switchable, and I'm not

going to show you the scars I got the last time I proposed

authoritative hooks. Next you'll have to deal with defining what is

security behavior and what isn't. You wouldn't believe the debates

over the security implications, or lack thereof, of disk quotas.

Unless you're willing to take the approach that every conditional

in the kernel is a potential security checkpoint you are going to

miss someone's requirement and if you're willing to propose that,
The API issue cannot be solved if LSMs are going to implement

different behaviors. A reasonable subset can be addressed using

the POSIX P1003.1e/2c MAC definition plus the TSIG APIs. It is

unfortunate that SELinux has gone in a completely different
A specific table configuration sounds an awful lot like a

specific SELinux Policy. Either way, your configuration is
In addition to tools, there's the labor and money intensive Common

Criteria Evaluation Process.
Casey Schaufler

casey@schaufler-ca.com

-

Yup, see the top of http://www.research.ibm.com/vali/
Pretty cool work that really should be continued.
-serge

-

Woof. It weren't pretty, and I've carefully archived it so as
The ss interface provides no advantage over the LSM interface that
Which is the same for LSM. There are a bunch of LSM hooks that Smack

does not need, and going into SELinux code to choose to do nothing
The image that just flashed into my brain had a disturbing

similarity to STREAMS modules, but spread everywhere, not just

in the tty code. And anyone who thinks that there are too many

LSM hooks now would have kittens over this. I don't think it's a

bad idea, but I don't see how it would change the well documented

disputes regarding what kinds of security behavior it ought to

provide for. How would it help AppArmor, for example? I'm willing

to bet (a beer or equivalence) that anything that helped there

would face stiff resistance simply because it helped there.
I could see it working if you restricted the interface to dealing

with things that have security blobs, or even better to subjects

and objects. But that's my security mindset, and I think pretty

much yours, too. It's the policies that don't use good old
Smack uses text strings for labels. It's amazing how many of the API

issues evaporate when the only thing you have to do with your labels is

compare them and print them. With the labels for processes available

through /proc, and the labels for most things available via getxattr(2)

and its variants the API issue seems hard to get worked up about. If

ls(1) had an option to show selected extended attributes, and it really

should by now, it wouldn't require fixing at all. Now sshd, login, and

the rest of the authentification gaggle are going to need policy

specific behavior so I feel no serious need to provide common API there.

Smack is designed to make this easy because I had to do it the hard

way before and didn't like it much.
Casey Schaufler

casey@schaufler-ca.com

-

Btw, one thing that is true: while both servers and desktop cares about

latency, it's often easier to *see* the issues on the desktop (or hear

them: audio skipping).
But that doesn't mean that the server people wouldn't care, and it doesn't

mean that scheduling would be "fundamentally different" on servers or the

desktop.
In contrast, security really *is* fundamentally different in different

situations. For example, I find SELinux to be so irrelevant to my usage

that I don't use it at all. I just don't have any other users on my

machine, so the security I care about is in firewalls etc. And that really

*is* fundamentally different from a system that has shell access to its

users. Which in turn is fundamentally different from one that has some

legal reasons why it needs to have a particular kind of security. Which in

turn is fundamentally different from ....
You get the idea.
It boils down to: "scheduling is scheduling", and doesn't really change

apart from the kind of decisions that are required by any scheduler (ie RT

vs non-RT etc). Everybody wants the same thing in the end: low latency for

loads where that matters, high bandwidth for loads where that matters.

It's not a "one user has only one kind of load". Not at all.
Security, on the other hand, very much does depend on the circumstances

and the wishes of the users (or policy-makers). And if we had one module

that everybody would be happy with, I'd not make it pluggable either. But

as it is, we _know_ that's not the case. 
		Linus

-

And you claim you are not a security expert :-)
Crispin
--

Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/

	       Itanium. Vista. GPLv3. Complexity at work
-

That you know about...
The value of SELinux (or indeed any system compartmentalising access and

limiting damage) comes into play when you get breakage - eg via a web

browser exploit.
Yes SELinux is much more relevant to servers, and really comes into its

own when its used to write custom rulesets and enforce corporate policy

("No you can't run that screensaver that arrived by email").
Alan

-

well,  being sick of the number of times one has to upgrade the browser

for exploits,  I addressed it in a different way.
I ran firefox setuid to a different (not my main user),  uid+gid,  gave

my main account that gid as a supplemental group,  and gave that uid

access to the X magic cookie.
...  which only changes the nature of any exploit that might occur - any

injected code would have to go via X to attack my main account.
DF

-

You need to use runxas to get any kind of real security.

-

Interesting script - sad how everyone reinvents equivalent things.
I had been experimenting with running the whole lot under Xnest,

with two extra users - one for the Xnest which had the main X

cookie, and another for the browser.  But found that it was just

too awkward (since I use multiple browser windows as well a tabs).
So I ended up trading a small security gain vs usablity.
The other thing I started playing with was the NX version of Xnest,

since it allows for a rootless server...
DF

-

Not so much incompetent as religious fundamentalist.  Which is worse.
  OG.

-

Yep, I've been tracking Casey's work on this since the first patch and sending

comments when appropriate.  I'm going to take a look at the latest rev of the

patch and if anything looks awry I'll be sure to let Casey know.
The only real wart that still remains from the original patch is the code in

smk_cipso_doi() which has a nice comment at the top saying that Paul and

Casey need to work out an appropriate interface between NetLabel and SMACK.

We punted on it before because SMACK's future was still a bit uncertain and

SELinux has no need for an interface like this at present.  Now that SMACK

looks to be queued up for 2.6.24 it's time to revisit this discussion.
--

paul moore

linux security @ hp

-

I've been leading with code, and working on the documentation
Over time the Smack application changes will fairly

closely follow those for SELinux, e.g. cron, login,

su, the MLS window environment. There won't be a major

set of new applications or libraries as there isn't a
Paul was the first person to whom I sent the patch. I would be
The original intent was an "external" vs "internal" distinction,
Thank you. The current set of interfaces and practices make

kernel coding much easier than it was back in the Unix days.
Casey Schaufler

casey@schaufler-ca.com

-

The issue was moot because rulesets never get removed in the current

implementation. I had missed that. If that ever changes RCU would be likely 
I personally consider these IP options it uses to be pretty useless. Who could

ever use that without cryptographic authentication? Clearly when they

were designed in the original IP spec long ago the designers didn't understand

network security very well because the whole field was at its infancy. And

CIPSO doesn't solve any of these fundamental issues.
It assumes a trusted network which is a very dangerous assumption.  I don't

think that was in the original patch I looked at, I surely would have

objected to it.
Perhaps take the network part out? I guess SMACK would be useful

locally even without questionable network support.
-Andi

-

Real quickly, CIPSO doesn't try to. CIPSO attaches attribute information

to the packet, and that's it. Smack uses CIPSO because it's available

and sufficient to get the required information about packets from one

task to another inside the box. It does the job going off box, too.
That would break sockets. I really doubt that you're suggesting that

cryptographic authentication is required on the loopback interface.
Casey Schaufler

casey@schaufler-ca.com

-

It does not as far as I can see. The IETF seems to have had very good
First rule of network security: don't trust the network. And you seem

to trust your security to the network which is just double plus bogus.
Without authentication it's completely useless. I don't understand

how you can disregard that as "separate issue". Security is only

secure if you plugged all applicable holes; without that it's useless
You didn't solve sockets security, so they cannot be really broken.
And it's not that network security isn't well understood and well supported

in Linux by various proven subsystems (ipsec, netfilter, ssh, openssl etc.). 
For local communication security there are better options like Unix sockets

which can be protected by standard file system protections. And most

networking is not over loopback after all. Only handling loopback is so limited

that it's bordering to useless.
And again we have plenty of proven networking security solutions anyways.

They all work fine over loopback too. I don't really see what SMACK can add here.
-Andi
-

but this is so silly that I have to object.
saying that any security short of perfect security is worthless and we

shouldn't bother is wrong, and needs to be countered every time it's

said.
as ted pointed out in response to your other comments, it very much

depends on where the trust boundry is. so from the point of view of

absolute security you are wrong.
but even more then that, the vast majority of the time absolute security

isn't what matters, relative security is what matters (the model of "I

don't have to outrun the bear, I only have to outrun you") and in these

envrionments things that are less then absolute can still be very useful.
how useful they are depends on a lot of details, and in the case of the

network security being discussed it sure sounds like it's pretty close to

useless if you can't trust the network and the other machines on it, but

that is seperate from the mentality that "anything less then perfect

security is worthless and shouldn't be bothered with" which is what I'm

objecting to.
David Lang

-

CIPSO is supported on SELinux as well. It certainly has uses where IPSec

is excessive. One example is someone I talked to recently that basically

has a set of blade systems connected with a high speed backplane that

looks like a network interface. CIPSO is useful in this case because

they can't afford the overhead of IPSec but need to transfer the level

of the connection to the other machines. The backplane is a trusted

network and that isn't a dangerous assumption in this case.
CIPSO also lets systems like SELinux and SMACK talk to other trusted

systems (eg., trusted solaris) in a way they understand. I don't

regularly support CIPSO as I believe IPSec labeling is more useful in

more situations but that doesn't mean CIPSO is never useful.
-

Security that isn't secure is not really useful. You might as well not

bother.
-Andi
-

As always, it depends on your environment.  There are people who are

using Linux systems where trusting the network makes sense.  For

example, if you're on a battleship, say, or all of the machines are in

a cluster which is inside a Tempest-shielded machine room with a

massive combination lock that you might find on a bank vault, or if

you're environment where network cables are protected by pressurized

pipes (so any attempt to tamper with or tap the cables causes a

pressure drop which sets off the alarm which summons the Marines armed

with M-16's...).
(I've been inside classified machine rooms, which is why my laptop has

the 'Unclassified' label on it; it's needed so people can easily

eyeball it and know that I'm not allowed to connect it to any of the

classified networks.  And those are just the less serious machine

rooms.  In the really serious classified areas with the bank

vault-like doors, and the copper-tinted windows, I'm not allowed to

bring in an unclassified laptop at all --- and yes, Linux is being

used in such environments.  And yes, they do sometimes use IPSO and/or
There are different kinds of security.  Not all of them involve

cryptography and IPSEC.  Some of them involve armed soldiers and air

gap firewalls.  :-)
Yes, normally the network is outside the Trusted Computing Base (TCB),

but a cluster of Linux machines in a rack is roughly the same size of

a huge Unix server tens year ago --- and it's not like Ethernet is any

more secure than the PCI bus.  So why do we consider communications

across a PCI bus secure even though they aren't encrypted?  Why,

because normally we assume the PCI bus is inside the trust boundary,

and so we don't worry about bad guys tapping communications between

the CPU and the hard drive on the PCI bus.
But these days, it is obviously possible to create clusters where

certain network interfaces are only connected to machines contained

completely inside the trust boundary, just like a PCI bus in a

traditional server.  So don't be so...
[ message continues ]

Sorry I'm a bit late to the discussion (been busy doing "weekend" things), but

I see that Casey, Josh, and Ted have already given a pretty good explanation

of why CIPSO is not as "evil" as it appears at first glance.  I won't restate

the points they have already made, but I think there are two other points

worth mentioning:
The first is that CIPSO options are immutable, which means they work

wonderfully with IPsec.  Label integrity can be provided through the use of

AH and/or tunneled ESP, label confidentiality can be provided through

tunneled ESP.  While the SELinux specific labeled IPsec implementation we

currently have in the kernel is nice if you are talking to other SELinux

machines, it has a very real handicap in that you can't use it to talk

anything else.  CIPSO, or CIPSO in combination with standard, non-labeled

IPsec, can be used to talk to pretty much any trusted OSs out there.

Adherence to standards and interoperability with other OSs have always been a

key factor of Linux's acceptance into new areas; support for CIPSO is just

another part of this drive for greater interoperability.
The second point I wanted to make is that in the course of putting together

the CIPSO implementation in the kernel I ended up talking with a few people

who were involved in the original TSIG effort and the mess with the IETF.

From what I could gather, the main technical complaint (other than a variety

of political complaints which aren't relevant to our discussion here) was

that CIPSO options are difficult to parse (they are, look at the format -

it's an option within an option format - yuck) and the intermediate node

vendors did not like it all (too much work to do in a fastpath ASIC).  After

all, look at the [R]IPSO RFC, dated only eight months earlier, and there is

no cryptographic "special sauce" in that protocol.
CIPSO isn't for everyone, I'll be the first to admit that.  However, if you

look at the mailing list archive for the Linux LSPP effort, the SELinux...
[ message continues ]

PCI busses normally don't have routers to networks outside the box connected
With your argumentation we could also just disable all security

in these situations (as in null LSM to save some overhead); after all these

systems are protected by armed guards.  If someone gets past the guards

they could connect their laptop to the network and fake all the "secured"

packets. If you assume that won't happen why do you need computer security at all?
Anyways; if someone wants to cripple their security for some

performance this way they can surely do this; but i don't think we should

offer it as a default configuration option (just as we don't have a

CONFIG_NULL_LSM even though there are undoubtedly systems that don't

care about permission checking[1]) 
-Andi
[1] I bet I gave the linux-tiny crowd an idea now ;-)
-

You would need authoritative LSM hooks for this. The current LSM

additional restrictions model does not provide for this.
Casey Schaufler

casey@schaufler-ca.com

-

The whole *point* is that the routers are interconnecting boxes inside

the cluster, and none of them connect to the outside world.  It's no

different than a SCSI cable connecting to JBOD in a separate box, or a

Fiber Channel router connected to a SAN network connecting to a

storrage array.  The SCSI or FC buses aren't encrypted either, and the

in the Fiber channel case we have a router --- yet people aren't

stressing out that we're not encrpying the traffic over the Storage

Area Network?  Why?  Because it's understood the network stays inside

the machine room.  The same thing can true for Ethernet --- think
If you get past all of the guards, you can usually reboot in single

user mode, and get root anyway.  If you have physical access to the

computer, you're generally doomed anyway, unless you are willing to

pay the cost of encrypting everything on every single disk platter.

(And yes, in the more paranoid environments, where it's too expensive

to have 7x24 armed guards, maybe that makes sense.)
The point of something like CIPSO is because you want to label the

packets so the otherside knows how they should be treated.  We don't

encrypt unix permission bits on most on-disk filesystems, either.  Yet

I haven't heard people saying that just because someone could break

into a machine room, disconnect the JBOD from the computer, hook up

the JBOD to their laptop, and futz with the Unix permission bits,

rehook up the JBOD and reboot, that Unix permission bits are useless,

and we should leave all files at mode 777 --- since clearly we're not

secure against someone who can break into the machine room.....  
I *hope* that sounds absurd, right?
					- Ted
-

I'm not sure this was discussed on the list, but as long as Casey doesn't

get rid of the magic symlinks (smackfs_follow_link), there's a clear NACK

from the VFS perspective.
Otherwise the code looks pretty well written, alhough a run through

checkpath.pl to fix the lose end might help.  Oh, and please to compile-time

initializations for the spinlocks and mutex currently initializes in

smack_init.  Also the -Inet/netlabel looks rather odd, please work with

the netlabel maintainer to move the required files to the include/

hierachy.

-

Any rationale for this NACK?

Caseys patch doesn't add something crazy like "make symlinks depend on

environment variables"; also, we already have something similar in-tree:

/proc/self.
Thomas

-

Paul and I discussed this earlier, and will again.
Thank you.
Casey Schaufler

casey@schaufler-ca.com

-