Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Smack is the Simplified Mandatory Access Control Kernel.

 Documentation/Smack.txt       |  104 +
 security/Kconfig              |    1 
 security/Makefile             |    2 
 security/smack/Kconfig        |   10 
 security/smack/Makefile       |    9 
 security/smack/smack.h        |  207 ++
 security/smack/smack_access.c |  345 ++++
 security/smack/smack_lsm.c    | 2685 ++++++++++++++++++++++++++++++++
 security/smack/smackfs.c      | 1201 ++++++++++++++
 9 files changed, 4564 insertions(+)

- 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 Paul Moore is the man. Maybe he'd be interested in taking a look over it (please?)

Quoted 4 lines

- 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?

Yes that's the important thing.

Quoted 3 lines

- 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?

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 needed though.

Quoted 3 lines

- hm, netlabels. Who might be a suitable person to review that code? Seems that Paul Moore is the man. Maybe he'd be interested in taking a look over it (please?)

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.

It does the job going off box, too.

The authentication issues are very real, but a separate issue.

Quoted 6 lines

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.

That would break sockets.

I really doubt that you're suggesting that
cryptographic authentication is required on the loopback interface.

Quoted 1 line

The authentication issues are very real, but a separate issue.

First rule of network security: don't trust the network.

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 and you might as well not bother.

Quoted 4 lines

- hm, netlabels. Who might be a suitable person to review that code? Seems that Paul Moore is the man. Maybe he'd be interested in taking a look over it (please?)

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.

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.

Quoted 2 lines

CIPSO also lets systems like SELinux and SMACK talk to other trusted systems (eg., trusted solaris) in a way they understand.

Perhaps, but is the result secure? I have severe doubts.

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

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 don't be so quick to dismiss something like CIPSO out of hand, just because it doesn't use IPSEC.

Quoted 3 lines

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.

PCI busses normally don't have routers to networks outside the box connected to them.

Quoted 2 lines

So don't be so quick to dismiss something like CIPSO out of hand, just because it doesn't use IPSEC.

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 ;-)

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 quick to dismiss something like CIPSO out of hand, just because it doesn't use IPSEC.

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

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. I'm more thinking "let's merge it and see if people use it".

Quoted 5 lines · Andrew Morton

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.

Quoted 2 lines

I'd have trouble declaring that "but" to be a reason to not merge smack. I'm more thinking "let's merge it and see if people use it".

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.

Quoted 5 lines · Andrew Morton

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.

Quoted 2 lines

I'd have trouble declaring that "but" to be a reason to not merge smack. I'm more thinking "let's merge it and see if people use it".

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.

Quoted 3 lines · On Sat, 29 Sep 2007 17:20:36 -0700 Casey Schaufler <[email protected]>…

Smack is the Simplified Mandatory Access Control Kernel.

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. I'm more thinking "let's merge it and see if people use it".

Quoted 11 lines

 Documentation/Smack.txt       |  104 +
 security/Kconfig              |    1 
 security/Makefile             |    2 
 security/smack/Kconfig        |   10 
 security/smack/Makefile       |    9 
 security/smack/smack.h        |  207 ++
 security/smack/smack_access.c |  345 ++++
 security/smack/smack_lsm.c    | 2685 ++++++++++++++++++++++++++++++++
 security/smack/smackfs.c      | 1201 ++++++++++++++
 9 files changed, 4564 insertions(+)

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 Paul Moore is the man. Maybe he'd be interested in taking a look over it (please?)

- some parts of the code use the "smack_foo" naming convention and other parts use "smk_foo". Seems odd. Deliberate?

- According to git-log, you haven't merged any kernel code at all in at least 5.5 years. This patch makes it look like you've been doing kernel full time for a decade. That thing in my hand is a hat.

- hm, netlabels. Who might be a suitable person to review that code? Seems that Paul Moore is the man. Maybe he'd be interested in taking a look over it (please?)

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

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.

Quoted 3 lines · James Morris

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

Hell f*cking NO!

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

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

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

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

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

Do you really want to encourage people to roll their own security module rather than working toward a common security architecture and a single balanced solution (which doesn't necessarily mean SELinux, mind you, but
certainly could draw from parts of it)? As with pluggable schedulers,
the LSM approach prevents cross pollination and forces users to make poor choices.

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?

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.

Quoted 2 lines · Stephen Smalley

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

Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis.

Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers.

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.

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?

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

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.

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.

Quoted 3 lines

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.

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

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.

Quoted 4 lines · Bill Davidsen

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 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 anybody on slashdot).

Quoted 2 lines

You say "performance" as if it had universal meaning.

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 tripping. And anybody who claims that desktop workloads are so radically different from server workloads (or that the hardware is so different) is just totally out to lunch.

So next time, think five minutes before you start your argument.

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 goal is <10ms, I will not sacrifice capacity to do it.

Quoted 2 lines

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?

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. throughput may be very different on one server than another or a desktop.

Quoted 3 lines

Why do people believe that desktop doesn't have multiple processors or through-put intensive loads? Why are people continuing this *idiotic* scheduler discussion?

Because people can't get you to understand that one size doesn't fit all (and I doubt I've broken through).

To get back to security: I didn't want pluggable security because I thought that was a technically good solution. No, the reason Linux has LSM (and yes, I was the one who pushed hard for the whole thing, even if I didn't actually write any of it) was because the problem wasn't technical to begin with.

It was social/political and administrative.

See? Another fundamental difference between schedulers and security modules.

But no, that's not really why we have LSM. I'd have *much* preferred to have one unified security module setup that we could all agree on, and no pluggable security modules. It was not to be - and the reason we have LSM is not because "it makes more sense than a CPU scheduler", but simply because "people didn't actually get anything done at all, because they just argued about what to do".

In the CPU schedulers, Ingo still gets work done, even though people argue about it. So we haven't needed to go to the extreme of an "LSM for CPU schedulers", because the arguments don't actually hold up the work.

And THAT is what matters in the end.

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.

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

So I propose that if people want to work towards a one true linux solution for additional security checks, then they should look towards the linux firewalling code. It works and it seems to very nicely allow cooperations between different groups. For the people who will scream mixing security models causes problems, the answer is simple recommend users don't set up their policies that way.

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

Quoted 2 lines · Eric W. Biederman

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

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 changed by the "owner" of the file, if we don't entirely trust them,

Quoted 5 lines

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.

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 the same namespace).

Quoted 4 lines

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.

Well, I wouldn't go so far as the "ordinary mortals can understand it" part; it's still pretty high on the obtuse-o-meter.

Quoted 7 lines

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

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.

Quoted 3 lines

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler. Probably a fair amount of that just means better tools.

Quoted 3 lines · Kyle Moffett

Quoted 1 line · Eric W. Biederman

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.

Quoted 1 line

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 the same namespace).

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 that solves a wider set of problems.

Quoted 3 lines

Quoted 1 line

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.

Well, I wouldn't go so far as the "ordinary mortals can understand it" part; it's still pretty high on the obtuse-o-meter.

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 perception...

Quoted 10 lines

Quoted 1 line

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

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

Quoted 6 lines

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.

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 compiled in.

Quoted 3 lines

Quoted 1 line

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler. Probably a fair amount of that just means better tools.

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.

Quoted 20 lines · Eric W. Biederman

Quoted 8 lines · Kyle Moffett

Quoted 6 lines · Eric W. Biederman

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.

Quoted 4 lines

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 the same namespace).

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.

Quoted 6 lines

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 that solves a wider set of problems.

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 be about non-exclusive information restriction.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

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.

Quoted 7 lines

Quoted 2 lines

Well, I wouldn't go so far as the "ordinary mortals can understand it" part; it's still pretty high on the obtuse-o-meter.

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 perception...

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 problems:

1) Half the tools are still somewhat beta-ish and under heavy development. Furthermore the semi-official reference policy is nowhere near comprehensive and pretty ugly to read (go back to the point about the tools being beta-ish).

2) If you break your system description or translation tools then instead of just your network dying your entire *system* dies.

Quoted 31 lines

Quoted 24 lines

Quoted 8 lines

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

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

Quoted 6 lines

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.

Quoted 6 lines

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 compiled in.

Now see I think *THAT* is where Casey should be going with his SMACK code. Don't add another LSM, start looking at SELinux and figuring out what parts he does not need and how they can be parameterized out at build time for smaller systems.

On the other hand, the "user" and "role" fields in SELinux are already fairly flexible. The one constant is that user=>role and role=>type must both be allowed for a label to be valid. Other than that, the constraints specify what must be true for a transition to be allowed. For example the standard strict reference policy includes this bit:

constrain process transition (

	(u1 == u2) or
	(t1 == can_change_process_identity and t2 == process_user_target) or
	(t1 == cron_source_domain and (t2 == cron_job_domain or u2 ==  
system_u)) or
	(t1 == can_system_change and u2 == system_u) or
	(t1 == process_uncond_exempt)

);

Basically all constraints on a particular access vector must be satisfied for that to be allowed (in addition to other things). For the above example, a process running exec() may only change its user if one of the following:

* It's a login-like program and is starting a user entrypoint
* It's a cron-like program and is starting a user or system cronjob
* It's a process allowed to start system processes (admin runs
initscripts)
* It's unconditionally exempt

By creating types and assigning meaningful attributes to those types you may restrict the changing of the "user" and "role" however you would like, including not at all.

Really SELinux is just a fairly elaborate security state-machine. Each process on the system is in a given "state", defined by its label, and "state transitions" are only allowed based on the rules defined in the database. Since there are 4 extremely common security models that people like to combine there are 4 fields in each SELinux label:
(A) User: User A may not poke user B's processes/data, even if
they happen to be running in the same UNIX UID
(B) Role: Users may only perform operations for the role they are
currently logged in as
(C) Type-enforcement: An apache process may only read files that
it needs to operate correctly
(D) Multi-level: Top-secret data can't magically become
unclassified

Perhaps the thing to do would be to make it possible to compile out the portions which people don't want. That would certainly satisfy Casey, he would build only the "Type-enforcement" portion or only the "Multi-level" portion and be able to do exactly the same things he does now with a bit finer granularity of operations. By defining the lists of operations he cares about for "r" (read), "w" (write), "x" (exec), "a" (append), and requires-capabilities, you can just give those permissions directly in a simplified SELinux-type policy.

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler.

Quoted 1 line

Quoted 1 line

Probably a fair amount of that just means better tools.

Quoted 5 lines

How about thinking of it another way.

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

Quoted 7 lines

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.

Quoted 6 lines

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.

Well the major problem here is the performance one. As anybody who has tried to do a thousand-linear-rule IPtables set will quickly tell you, it makes performance go all to hell. Good iptables frontends like shorewall build little subchains to keep the fast-path as efficient as possible but regardless the search is a linear rule- traversal (IE: O(N) where N is the number of rules you had to test). In order to get good enough performance out of SELinux they had to *start* with an O(log(N) rule traversal which means that execution- order-style rules are impossible, so you *MUST* limit the fields and prevent any overlap between rules. For example, in SELinux nobody writes "deny" rules because the interpretation-order is undefined. Instead you only write "allow" rules for the things you actually want to allow. The one exception is "neverallow" rules which are verified at compile time as sanity checks and never actually loaded in the kernel.

Cheers,
Kyle Moffett

Quoted 39 lines · --- Kyle Moffett

Quoted 20 lines · Eric W. Biederman

Quoted 8 lines · Kyle Moffett

Quoted 6 lines · Eric W. Biederman

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.

Quoted 4 lines

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 the same namespace).

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.

Quoted 6 lines

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 that solves a wider set of problems.

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".

Quoted 8 lines

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 be about non-exclusive information restriction.

Yes. Isolation is a much simpler problem than access control.

Quoted 78 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

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.

Quoted 7 lines

Quoted 2 lines

Well, I wouldn't go so far as the "ordinary mortals can understand it" part; it's still pretty high on the obtuse-o-meter.

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 perception...

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 problems:

1) Half the tools are still somewhat beta-ish and under heavy development. Furthermore the semi-official reference policy is nowhere near comprehensive and pretty ugly to read (go back to the point about the tools being beta-ish).

2) If you break your system description or translation tools then instead of just your network dying your entire *system* dies.

Quoted 31 lines

Quoted 24 lines

Quoted 8 lines

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

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

Quoted 6 lines

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.

Quoted 6 lines

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 compiled in.

Quoted 4 lines

Now see I think *THAT* is where Casey should be going with his SMACK code. Don't add another LSM, start looking at SELinux and figuring out what parts he does not need and how they can be parameterized out at build time for smaller systems.

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 the size and complexity of the implementation.

Quoted 46 lines

On the other hand, the "user" and "role" fields in SELinux are already fairly flexible. The one constant is that user=>role and role=>type must both be allowed for a label to be valid. Other than that, the constraints specify what must be true for a transition to be allowed. For example the standard strict reference policy includes this bit:

constrain process transition (

	(u1 == u2) or
	(t1 == can_change_process_identity and t2 == process_user_target) or
	(t1 == cron_source_domain and (t2 == cron_job_domain or u2 ==  
system_u)) or
	(t1 == can_system_change and u2 == system_u) or
	(t1 == process_uncond_exempt)

);

Basically all constraints on a particular access vector must be satisfied for that to be allowed (in addition to other things). For the above example, a process running exec() may only change its user if one of the following:

* It's a login-like program and is starting a user entrypoint
* It's a cron-like program and is starting a user or system cronjob
* It's a process allowed to start system processes (admin runs
initscripts)
* It's unconditionally exempt

By creating types and assigning meaningful attributes to those types you may restrict the changing of the "user" and "role" however you would like, including not at all.

Really SELinux is just a fairly elaborate security state-machine. Each process on the system is in a given "state", defined by its label, and "state transitions" are only allowed based on the rules defined in the database. Since there are 4 extremely common security models that people like to combine there are 4 fields in each SELinux label:
(A) User: User A may not poke user B's processes/data, even if
they happen to be running in the same UNIX UID
(B) Role: Users may only perform operations for the role they are
currently logged in as
(C) Type-enforcement: An apache process may only read files that
it needs to operate correctly
(D) Multi-level: Top-secret data can't magically become
unclassified

Quoted 8 lines

Perhaps the thing to do would be to make it possible to compile out the portions which people don't want. That would certainly satisfy Casey, he would build only the "Type-enforcement" portion or only the "Multi-level" portion and be able to do exactly the same things he does now with a bit finer granularity of operations. By defining the lists of operations he cares about for "r" (read), "w" (write), "x" (exec), "a" (append), and requires-capabilities, you can just give those permissions directly in a simplified SELinux-type policy.

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 Smack.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler.

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 it simpler would conflict with the design goal of finer granularity.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Probably a fair amount of that just means better tools.

Now what kind of tools are you talking about? Static analysis? Data flow diagrammers for Java?

Quoted 9 lines

Quoted 9 lines

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.

Quoted 3 lines

Quoted 3 lines

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.

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 ago, I would hate to have to regurgitate all those discussions.

...

Quoted 6 lines

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 the size and complexity of the implementation.

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 obstacles you ran up against.

...

Quoted 4 lines

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 Smack.

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 is itself general and not tied to TE.

Quoted 9 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler.

Quoted 3 lines

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.

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 to apply it.

Quoted 17 lines

SELinux is designed to increase in complexity as it evolves. Making it simpler would conflict with the design goal of finer granularity.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Probably a fair amount of that just means better tools.

Now what kind of tools are you talking about? Static analysis? Data flow diagrammers for Java?

Quoted 9 lines

Quoted 9 lines

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.

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

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.

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 ago, I would hate to have to regurgitate all those discussions.

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.

Quoted 6 lines · Casey Schaufler

Quoted 4 lines · --- Kyle Moffett

Quoted 3 lines · Eric W. Biederman

Quoted 1 line · Kyle Moffett

On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Yes. Currently with containers we are taking that one step farther as that solves a wider set of problems.

So containers are exclusive subsets of "the system" while LSM should be about non-exclusive information restriction.

Yes. Isolation is a much simpler problem than access control.

Quoted 9 lines

Quoted 4 lines

Quoted 4 lines

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.

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 ago, I would hate to have to regurgitate all those discussions.

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.

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.

Quoted 4 lines · --- "Eric W. Biederman

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.

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.

Quoted 8 lines · Casey Schaufler

Quoted 4 lines · --- "Eric W. Biederman

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.

Quoted 7 lines

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.

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?

Quoted 8 lines · Casey Schaufler

Quoted 4 lines · --- "Eric W. Biederman

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.

Quoted 7 lines

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.

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?

Quoted 39 lines · --- Kyle Moffett

Quoted 20 lines · Eric W. Biederman

Quoted 8 lines · Kyle Moffett

Quoted 6 lines · Eric W. Biederman

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.

Quoted 4 lines

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 the same namespace).

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.

Quoted 6 lines

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 that solves a wider set of problems.

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".

Quoted 8 lines

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 be about non-exclusive information restriction.

Yes. Isolation is a much simpler problem than access control.

Quoted 78 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

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.

Quoted 7 lines

Quoted 2 lines

Well, I wouldn't go so far as the "ordinary mortals can understand it" part; it's still pretty high on the obtuse-o-meter.

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 perception...

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 problems:

1) Half the tools are still somewhat beta-ish and under heavy development. Furthermore the semi-official reference policy is nowhere near comprehensive and pretty ugly to read (go back to the point about the tools being beta-ish).

2) If you break your system description or translation tools then instead of just your network dying your entire *system* dies.

Quoted 31 lines

Quoted 24 lines

Quoted 8 lines

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

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

Quoted 6 lines

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.

Quoted 6 lines

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 compiled in.

Quoted 4 lines

Now see I think *THAT* is where Casey should be going with his SMACK code. Don't add another LSM, start looking at SELinux and figuring out what parts he does not need and how they can be parameterized out at build time for smaller systems.

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 the size and complexity of the implementation.

Quoted 7 lines · Casey Schaufler

...
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 the size and complexity of the implementation.

(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 suggesting was that selinux be re-written on top of smack.

:)

Quoted 9 lines · --- "Serge E. Hallyn

Quoted 7 lines · Casey Schaufler

...
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 the size and complexity of the implementation.

Quoted 7 lines

(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 suggesting was that selinux be re-written on top of smack.

:)

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.

Quoted 3 lines · Casey Schaufler

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

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?

(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 suggesting was that selinux be re-written on top of smack.

Quoted 4 lines · Kyle Moffett

Quoted 2 lines · Eric W. Biederman

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

Quoted 8 lines

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 changed by the "owner" of the file, if we don't entirely trust them,

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 number of times we say -EPERM.

Quoted 9 lines

Quoted 5 lines

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.

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 the same namespace).

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 that solves a wider set of problems.

Quoted 7 lines

Quoted 4 lines

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.

Well, I wouldn't go so far as the "ordinary mortals can understand it" part; it's still pretty high on the obtuse-o-meter.

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 perception...

Quoted 22 lines

Quoted 7 lines

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 kernel modules to decide if we should drop a packet. Each of those kernel modules provides a different capability that can be used to generate a firewall.

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

Quoted 5 lines

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.

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 compiled in.

Quoted 7 lines

Quoted 3 lines

I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored.

I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler. Probably a fair amount of that just means better tools.

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.

Quoted 12 lines · Eric W. Biederman

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.

Quoted 2 lines

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

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 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 want?

Quoted 3 lines

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.

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 to do system setup for automated testing. There is a learning curve in having to look at existing modules for maybe a few days to get started, but once you get started the policy modules do make it very easy to add to current policy.

"Serge E. Hallyn" <[email protected]> writes:
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 on the situation so I have a clue what I'm go.

Quoted 5 lines

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.

Thanks that sounds interesting.

Quoted 4 lines

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 want?

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 network firewall code?

Quoted 11 lines

Quoted 3 lines

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.

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 to do system setup for automated testing. There is a learning curve in having to look at existing modules for maybe a few days to get started, but once you get started the policy modules do make it very easy to add to current policy.

Ok. Interesting. Are these kernel modules?

Still while I get the general impression that selinux seems to be very close to a generic solution, and that selinux more or less has the architecture we might want. I don't get the impression that selinux does this at a level that is open to other people doing interesting things.

So I still ask the question can we move this functionality down to the LSM in a way that will solve the composition problem between multiple security modules?

It really seems to me that the LSM as currently structured creates a large barrier to entry for people who have just this little thing they want to do that is not possible with any existing security module.

Quoting Eric W. Biederman ([email protected]):

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 up to the distro, for instance, or a site local security administrator, to define policy, so that flexibility really is of very limited use?

Quoted 9 lines

Still while I get the general impression that selinux seems to be very close to a generic solution, and that selinux more or less has the architecture we might want. I don't get the impression that selinux does this at a level that is open to other people doing interesting things.

So I still ask the question can we move this functionality down to the LSM in a way that will solve the composition problem between multiple security modules?

I've tried :) At a less semantic and more purely technical level, using the stacker module. After a few years it was finally decided (at ksummit 2006) that it simply wasn't useful.

Now perhaps the problem was that I didn't address semantic issues. But it does sound to me like what you want is a particular flexible LSM. Be it LIDS or SELinux, or something new.

Quoted 4 lines

It really seems to me that the LSM as currently structured creates a large barrier to entry for people who have just this little thing they want to do that is not possible with any existing security module.

Yes and it's been made increasingly so far particularly because of the perceived potential for 'abuse'. So to be curt, allowing people like you describe to do something small and interesting is deemed far less important than making sure that the small thing they want to do fits within the LSM mandate and is not a non-upstream module.

So that is the concern you would need to address before any other.

Still, I do think that selinux policy modules may do just what you want. The main obstacle appears to be that the 'base' policy is so huge that it's tough to get started to do something small.

You also might want to check out LIDS, as its rules are set up pretty much the way you seem to want.

Quoted 4 lines · Eric W. Biederman

It really seems to me that the LSM as currently structured creates a large barrier to entry for people who have just this little thing they want to do that is not possible with any existing security module.

Yes and it's been made increasingly so far particularly because of the perceived potential for 'abuse'. So to be curt, allowing people like you describe to do something small and interesting is deemed far less important than making sure that the small thing they want to do fits within the LSM mandate and is not a non-upstream module.

So that is the concern you would need to address before any other.

Still, I do think that selinux policy modules may do just what you want. The main obstacle appears to be that the 'base' policy is so huge that it's tough to get started to do something small.

You also might want to check out LIDS, as its rules are set up pretty much the way you seem to want.

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

Quoted 2 lines · --- "Eric W. Biederman

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

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.

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

Quoted 2 lines

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

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 ?

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..

Quoted 8 lines · Alan Cox

Quoted 2 lines

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

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 ?

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 the LSM to help me achieve other things.

Quoted 4 lines

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.

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 different file permission system.

Quoted 11 lines · Eric W. Biederman

Quoted 8 lines · Alan Cox

Quoted 2 lines

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

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 ?

Quoted 7 lines

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.

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 enforce.

Quoted 5 lines

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 the LSM to help me achieve other things.

Quoted 14 lines

Quoted 4 lines

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.

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?

Quoted 2 lines

Certainly selinux seems too programmable to be considered just a different file permission system.

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.

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 because SMACK is a linear-lookup system (each rule must be matched in order) whereas SELinux is a globally-unique-lookup system (all rules are mutually exclusive and matched simultaneously). Essentially for each SMACK rule:
$SOURCE $DEST $PERM_BITS

We iterate over all of the classes represented in the access vector lists in $PERM_BITS and create rules for each one:

	allow { $SOURCE } { $DEST }:$PERM_CLASS { $PERM_VECTORS };

If you need SMACK to allow subtractive permissions then you need to expand that further, however I believe as an initial cut that it sufficient.

The only other task is to prepend the auto-generated object-class and access-vector lists to the policy and append the initial SIDs that smack wants various objects to have, as well as allowing the "smack" user the "priv" and "nopriv" roles and allowing those two roles entry into all of the SMACK types. The resulting SELinux-ified SMACK labels would go from:

SomeLabel (with CAP_MAC_OVERRIDE)
AnotherLabel
YetAnotherLabel

to:

smack:priv:SomeLabel
smack:nopriv:AnotherLabel
smack:nopriv:YetAnotherLabel

Casey, hopefully this gives you some ideas about how I think you could modify the SELinux code to compile out the "user" field and simplify the "role" field as needed. I'm still not seeing anything which SELinux cannot directly implement without additional code, even the "CAP_MAC_OVERRIDE" bit. If the semantics don't seem quite right, please provide details about how you think the models differ and I will try to address the concerns.

Quoted 1 line · --- Kyle Moffett

[snipped]

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.

Quoted 2 lines

from under that missunderstanding, and with people who are assuming that your policy has been done, "proving" the point.

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.

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

Quoted 5 lines

"Serge E. Hallyn" <[email protected]> writes:
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.

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 constraints placed by the host admin on vserver1.

Quoted 19 lines

So far I'm not ready to do anything yet but I'm keeping a weather eye on the situation so I have a clue what I'm go.

Quoted 5 lines

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.

Thanks that sounds interesting.

Quoted 4 lines

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 want?

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.

Quoted 6 lines

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 network firewall code?

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 up to the distro, for instance, or a site local security administrator, to define policy, so that flexibility really is of very limited use?

Quoted 11 lines

Quoted 10 lines

Quoted 3 lines

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.

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 to do system setup for automated testing. There is a learning curve in having to look at existing modules for maybe a few days to get started, but once you get started the policy modules do make it very easy to add to current policy.

Ok. Interesting. Are these kernel modules?

Policy modules, loaded through selinuxfs at any time using 'semodule'.

Quoted 9 lines

Still while I get the general impression that selinux seems to be very close to a generic solution, and that selinux more or less has the architecture we might want. I don't get the impression that selinux does this at a level that is open to other people doing interesting things.

So I still ask the question can we move this functionality down to the LSM in a way that will solve the composition problem between multiple security modules?

I've tried :) At a less semantic and more purely technical level, using the stacker module. After a few years it was finally decided (at ksummit 2006) that it simply wasn't useful.

Now perhaps the problem was that I didn't address semantic issues. But it does sound to me like what you want is a particular flexible LSM. Be it LIDS or SELinux, or something new.

Quoted 4 lines

It really seems to me that the LSM as currently structured creates a large barrier to entry for people who have just this little thing they want to do that is not possible with any existing security module.

Yes and it's been made increasingly so far particularly because of the perceived potential for 'abuse'. So to be curt, allowing people like you describe to do something small and interesting is deemed far less important than making sure that the small thing they want to do fits within the LSM mandate and is not a non-upstream module.

So that is the concern you would need to address before any other.

Still, I do think that selinux policy modules may do just what you want. The main obstacle appears to be that the 'base' policy is so huge that it's tough to get started to do something small.

You also might want to check out LIDS, as its rules are set up pretty much the way you seem to want.

(quoted diff) +0 -2

-serge
-

To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

It really seems to me that the LSM as currently structured creates a large barrier to entry for people who have just this little thing they want to do that is not possible with any existing security module.

Quoted 4 lines · --- "Eric W. Biederman

It really seems to me that the LSM as currently structured creates a large barrier to entry for people who have just this little thing they want to do that is not possible with any existing security module.

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.

Quoted 1 line · Eric W. Biederman

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

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 changed by the "owner" of the file, if we don't entirely trust them,

Quoted 8 lines · Linus Torvalds

Quoted 2 lines · Stephen Smalley

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

Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis.

Quoted 5 lines

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.

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.

Smack seems a perfectly good simple LSM module, its clean, its based upon credible security models and sound theory (unlike AppArmor).

Quoted 9 lines · Linus Torvalds

Quoted 3 lines · James Morris

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

Hell f*cking NO!

You security people are insane.

Quoted 6 lines

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.

Quoted 7 lines

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.

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?

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.

Quoted 2 lines · Andrew Morton

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

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

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

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

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

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

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

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

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

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

LSM will remain a magnet for bad ideas.

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

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

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

Quoted 11 lines

 Documentation/Smack.txt       |  104 +
 security/Kconfig              |    1 
 security/Makefile             |    2 
 security/smack/Kconfig        |   10 
 security/smack/Makefile       |    9 
 security/smack/smack.h        |  207 ++
 security/smack/smack_access.c |  345 ++++
 security/smack/smack_lsm.c    | 2685 ++++++++++++++++++++++++++++++++
 security/smack/smackfs.c      | 1201 ++++++++++++++
 9 files changed, 4564 insertions(+)

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.

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?

From: Casey Schaufler <[email protected]>

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 labeled "_" is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same label is permitted.
6. Any access requested that is explicitly defined in the loaded rule set is permitted.
7. Any other access is denied.

Rules may be explicitly defined by writing subject,object,access triples to /smack/load.

Smack rule sets can be easily defined that describe Bell&LaPadula sensitivity, Biba integrity, and a variety of interesting configurations. Smack rule sets can be modified on the fly to accomodate changes in the operating environment or even the time of day.

Some practical use cases:

Hierarchical levels. The less common of the two usual uses for MLS systems is to define hierarchical levels, often unclassified, confidential, secret, and so on. To set up smack to support this, these rules could be defined:

   C        Unclass rx
   S        C       rx
   S        Unclass rx
   TS       S       rx
   TS       C       rx
   TS       Unclass rx

A TS process can read S, C, and Unclass data, but cannot write it. An S process can read C and Unclass. Note that specifying that TS can read S and S can read C does not imply TS can read C, it has to be explicitly stated.

Non-hierarchical categories. This is the more common of the usual uses for an MLS system. Since the default rule is that a subject cannot access an object with a different label no access rules are required to implement compartmentalization.

A case that the Bell & LaPadula policy does not allow is demonstrated with this Smack access rule:

A case that Bell&LaPadula does not allow that Smack does:

    ESPN    ABC   r
    ABC     ESPN  r

On my portable video device I have two applications, one that shows ABC programming and the other ESPN programming. ESPN wants to show me sport stories that show up as news, and ABC will only provide minimal information about a sports story if ESPN is covering it. Each side can look at the other's info, neither can change the other. Neither can see what FOX is up to, which is just as well all things considered.

Another case that I especially like:

SatData Guard w
Guard Publish w

A program running with the Guard label opens a UDP socket and accepts messages sent by a program running with a SatData label. The Guard program inspects the message to ensure it is wholesome and if it is sends it to a program running with the Publish label. This program then puts the information passed in an appropriate place. Note that the Guard program cannot write to a Publish file system object because file system semanitic require read as well as write.

The four cases (categories, levels, mutual read, guardbox) here are all quite real, and problems I've been asked to solve over the years. The first two are easy to do with traditonal MLS systems while the last two you can't without invoking privilege, at least for a while.

Signed-off-by Casey Schaufler <[email protected]>

---

Changes since the previous version:

- Smack labels can now be up to 23 characters in length. My UI expert advised that 12 was the absolute minimum, and CIPSO starts to get troublesome at 30.

- Reading the SMACK64PACKET attribute from a socket used to provide the label of the last packet delivered. Now it provides the label of the packet returned by the most recent recv call, or ENOATTR if that value is not available. It's better to get no value than an incorrect value.

 Documentation/Smack.txt       |  104 +
 security/Kconfig              |    1 
 security/Makefile             |    2 
 security/smack/Kconfig        |   10 
 security/smack/Makefile       |    9 
 security/smack/smack.h        |  207 ++
 security/smack/smack_access.c |  345 ++++
 security/smack/smack_lsm.c    | 2685 ++++++++++++++++++++++++++++++++
 security/smack/smackfs.c      | 1201 ++++++++++++++
 9 files changed, 4564 insertions(+)

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/Documentation/Smack.txt linux-2.6.23-rc8-smack/Documentation/Smack.txt

Documentation/Smack.txt +92 -0

@@ -0,0 +1,104 @@
+
+
+    "Good for you, you've decided to clean the elevator!"
+    - The Elevator, from Dark Star
+
+Smack is the the Simplified Mandatory Access Control Kernel.
+Smack is a kernel based implementation of mandatory access
+control that includes simplicity in its primary design goals.
+
+Smack does not implement Domain Type Enforcement (DTE). If
+you want DTE Linux has an implementation called SELinux.
+Those who really want DTE are encouraged to use SELinux.
+Those who don't know what DTE is are encouraged to compare
+SELinux with Smack to determine which mechanisms are best
+suited to the problem at hand.
+
+Smack consists of three major components:
+    - The kernel
+    - A start-up script and a few modified applications
+    - Configuration data
+
+The kernel component of Smack is implemented as a Linux
+Security Modules (LSM) module. It requires netlabel and
+works best with file systems that support extended attributes,
+although xattr support is not strictly required. The Smack
+patch is (currently) self contained, except for Kconfig
+and Makefile changes in the security directory. It is safe
+to run a Smack kernel under a "vanilla" distribution.
+Smack kernels use the CIPSO IP option. Some network
+configurations are intolerant of IP options and can impede
+access to systems that use them as Smack does.
+
+The startup script etc-init.d-smack should be installed
+in /etc/init.d/smack and should be invoked early in the
+start-up process. On Fedora rc5.d/S02smack is recommended.
+This script ensures that certain devices have the correct
+Smack attributes and loads the Smack configuration if
+any is defined.
+
+A version of "ls" that provides a "-M" option to display
+Smack labels on long listing is available.
+
+A hacked version of sshd that allows network logins by users
+with specific Smack labels is available. This version does
+not work for scp. You must set the /etc/ssh/sshd_config
+line:
+   UsePrivilegeSeparation no
+
+The format of /etc/smack/usr is:
+
+   username smack
+
+In keeping with the intent of Smack, configuration data is
+minimal and not strictly required. The most important
+configuration step is mounting the smackfs pseudo filesystem.
+
+Add this line to /etc/fstab:
+
+    smackfs /smack smackfs smackfsdef=* 0 0
+
+and create the /smack directory for mounting.
+
+Smack uses extended attributes (xattrs) to store file labels.
+The command to set a Smack label on a file is:
+
+    # attr -S -s SMACK64 -V "value" path
+
+NOTE: Smack labels are limited to 23 characters. The attr command
+      does not enforce this restriction and can be used to set
+      invalid Smack labels on files.
+
+The smackfs filesystem treats symbolic links in a special way.
+The Smack label of the process is appended to the link value
+during resolution. To provide a /tmp that is available to users
+with multiple labels:
+
+    # mkdir /moldy
+    # mv /tmp /moldy/_
+    # ln -s /smack/tmp /tmp
+
+For each label users are going to use:
+
+    # mkdir /moldy/label
+    # chmod <appropriate-value> /moldy/label
+    # attr -S -s SMACK64 -V "label" /moldy/label
+
+If you don't do anything special all users will get the floor ("_")
+label when they log in. If you do want to log in via the hacked ssh
+at other labels use the attr command to set the smack value on the
+home directory and it's contents.
+
+You can add access rules in /etc/smack/accesses. They take the form:

Documentation/Smack.txt +2 -0

+
+

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/Kconfig linux-2.6.23-rc8-smack/security/Kconfig

security/Kconfig +1 -0

@@ -94,6 +94,7 @@ config SECURITY_ROOTPLUG
 	  If you are unsure how to answer this question, answer N.
 
 source security/selinux/Kconfig
+source security/smack/Kconfig
 
 endmenu
 

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/Makefile linux-2.6.23-rc8-smack/security/Makefile

security/Makefile +2 -0

@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_KEYS)			+= keys/
 subdir-$(CONFIG_SECURITY_SELINUX)	+= selinux
+subdir-$(CONFIG_SECURITY_SMACK)		+= smack
 
 # if we don't select a security model, use the default capabilities
 ifneq ($(CONFIG_SECURITY),y)

@@ -14,5 +15,6 @@ endif
 obj-$(CONFIG_SECURITY)			+= security.o dummy.o inode.o
 # Must precede capability.o in order to stack properly.
 obj-$(CONFIG_SECURITY_SELINUX)		+= selinux/built-in.o
+obj-$(CONFIG_SECURITY_SMACK)		+= commoncap.o smack/built-in.o
 obj-$(CONFIG_SECURITY_CAPABILITIES)	+= commoncap.o capability.o
 obj-$(CONFIG_SECURITY_ROOTPLUG)		+= commoncap.o root_plug.o

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/smack/Kconfig linux-2.6.23-rc8-smack/security/smack/Kconfig

security/smack/Kconfig +1 -0

+

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/smack/Makefile linux-2.6.23-rc8-smack/security/smack/Makefile

security/smack/Makefile +9 -0

@@ -0,0 +1,9 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
+
+EXTRA_CFLAGS += -Inet/netlabel

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/smack/smack_access.c linux-2.6.23-rc8-smack/security/smack/smack_access.c

security/smack/smack_access.c +345 -0

@@ -0,0 +1,345 @@
+/*
+ * Copyright (C) 2007 Casey Schaufler <[email protected]>
+ *
+ *      This program is free software; you can redistribute it and/or modify
+ *      it under the terms of the GNU General Public License as published by
+ *      the Free Software Foundation, version 2.
+ *
+ * Author:
+ *      Casey Schaufler <[email protected]>
+ *
+ */
+
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/sched.h>
+#include "smack.h"
+
+struct smack_known smack_known_unset = {
+	.smk_next	= NULL,
+	.smk_known	= "UNSET",
+	.smk_secid	= 1,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known smack_known_huh = {
+	.smk_next	= &smack_known_unset,
+	.smk_known	= "?",
+	.smk_secid	= 2,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known smack_known_hat = {
+	.smk_next	= &smack_known_huh,
+	.smk_known	= "^",
+	.smk_secid	= 3,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known smack_known_star = {
+	.smk_next	= &smack_known_hat,
+	.smk_known	= "*",
+	.smk_secid	= 4,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known smack_known_floor = {
+	.smk_next	= &smack_known_star,
+	.smk_known	= "_",
+	.smk_secid	= 5,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known smack_known_invalid = {
+	.smk_next	= &smack_known_floor,
+	.smk_known	= "",
+	.smk_secid	= 6,
+	.smk_cipso	= NULL,
+};
+
+struct smack_known *smack_known = &smack_known_invalid;
+/*
+ * The initial value needs to be bigger than any of the
+ * known values above.
+ */
+static u32 smack_next_secid = 10;
+
+extern struct smk_list_entry *smack_list;
+
+/**
+ * smk_access - determine if a subject has a specific access to an object
+ * @subject_label: a pointer to the subject's Smack label
+ * @object_label: a pointer to the object's Smack label
+ * @request: the access requested, in "MAY" format
+ *
+ * This function looks up the subject/object pair in the
+ * access rule list and returns 0 if the access is permitted,
+ * non zero otherwise.
+ *
+ * Even though Smack labels are usually shared on smack_list
+ * labels that come in off the network can't be imported
+ * and added to the list for locking reasons.
+ *
+ * Therefore, it is necessary to check the contents of the labels,
+ * not just the pointer values. Of course, in most cases the labels
+ * will be on the list, so checking the pointers may be a worthwhile
+ * optimization.
+ */
+int smk_access(char *subject_label, char *object_label, int request)
+{
+	u32 may = MAY_NOT;
+	struct smk_list_entry *sp;
+	struct smack_rule *srp;
+
+	/*
+	 * Hardcoded comparisons.
+	 *
+	 * A star subject can't access any object.
+	 */
+	if (subject_label == smack_known_star.smk_known ||
+	    strcmp(subject_label, smack_known_star.smk_known) == 0)
+		return -EACCES;
+	/*
+	 * A star object can be accessed by any subject.
+	 */
+	if (object_label == smack_known_star.smk_known ||
+	    strcmp(object_label, smack_known_star.smk_known) == 0)
+		return 0;
+	/*
+	 * An object can be accessed in any way by a subject
+	 * with the same label.
+	 */
+	if (subject_label == object_label ||
+	    strcmp(subject_label, object_label) == 0)
+		return 0;
+	/*
+	 * A hat subject can read any object.
+	 * A floor object can be read by any subject.
+	 */
+	if ((request & MAY_ANYREAD) == request) {
+		if (object_label == smack_known_floor.smk_known ||
+		    strcmp(object_label, smack_known_floor.smk_known) == 0)
+			return 0;
+		if (subject_label == smack_known_hat.smk_known ||
+		    strcmp(subject_label, smack_known_hat.smk_known) == 0)
+			return 0;
+	}
+	/*
+	 * Beyond here an explicit relationship is required.
+	 * If the requested access is contained in the available
+	 * access (e.g. read is included in readwrite) it's
+	 * good.
+	 */
+	for (sp = smack_list; sp != NULL; sp = sp->smk_next) {
+		srp = &sp->smk_rule;
+
+		if (srp->smk_subject == subject_label ||
+		    strcmp(srp->smk_subject, subject_label) == 0) {
+			if (srp->smk_object == object_label ||
+			    strcmp(srp->smk_object, object_label) == 0) {
+				may = srp->smk_access;
+				break;
+			}
+		}
+	}
+	/*
+	 * This is a bit map operation.
+	 */
+	if ((request & may) == request)
+		return 0;
+
+	return -EACCES;
+}
+
+/**
+ * smk_curacc - determine if current has a specific access to an object
+ * @object_label: a pointer to the object's Smack label
+ * @request: the access requested, in "MAY" format
+ *
+ * This function checks the current subject label/object label pair
+ * in the access rule list and returns 0 if the access is permitted,
+ * non zero otherwise. It allows that current my have the capability
+ * to override the rules.
+ */
+int smk_curacc(char *obj_label, u32 mode)
+{
+	int rc;
+
+	rc = smk_access(current->security, obj_label, mode);
+	if (rc == 0)
+		return 0;
+	
+	if (capable(CAP_MAC_OVERRIDE))
+		return 0;
+
+	return rc;
+}
+
+extern struct mutex smack_known_lock;
+
+/**
+ * smk_import_entry - import a label, return the list entry
+ * @string: a text string that might be a Smack label
+ * @len: the maximum size, or zero if it is NULL terminated.
+ *
+ * Returns a pointer to the entry in the label list that
+ * matches the passed string, adding it if necessary.
+ */
+struct smack_known *smk_import_entry(const char *string, int len)
+{
+	struct smack_known *skp;
+	char smack[SMK_LABELLEN];
+	int found;
+	int i;
+
+	if (len <= 0 || len > SMK_MAXLEN)
+		len = SMK_MAXLEN;
+
+	for (i = 0, found = 0; i < SMK_LABELLEN; i++) {
+		if (found)
+			smack[i] = '\0';
+		else if (i >= len || string[i] > '~' || string[i] <= ' ') {
+			smack[i] = '\0';
+			found = 1;
+		}
+		else
+			smack[i] = string[i];
+	}
+
+	if (smack[0] == '\0')
+		return NULL;
+
+	mutex_lock(&smack_known_lock);
+
+	for (skp = smack_known; skp != NULL; skp = skp->smk_next)
+		if (skp->smk_known == smack)
+			break;
+
+	if (skp == NULL) {
+		skp = kzalloc(sizeof(struct smack_known), GFP_KERNEL);
+		if (skp != NULL) {
+			skp->smk_next = smack_known;
+			strncpy(skp->smk_known, smack, SMK_MAXLEN);
+			skp->smk_secid = smack_next_secid++;
+			skp->smk_cipso = NULL;
+			spin_lock_init(&skp->smk_cipsolock);
+			smack_known = skp;
+		}
+	}
+
+	mutex_unlock(&smack_known_lock);
+
+	return skp;
+}
+
+/**
+ * smk_import - import a smack label
+ * @string: a text string that might be a Smack label
+ * @len: the maximum size, or zero if it is NULL terminated.
+ *
+ * Returns a pointer to the label in the label list that
+ * matches the passed string, adding it if necessary.
+ */
+char *smk_import(const char *string, int len)
+{
+	struct smack_known *skp;
+
+	skp = smk_import_entry(string, len);
+	if (skp == NULL)
+		return NULL;
+	return skp->smk_known;
+}
+
+/**
+ * smack_from_secid - find the Smack label associated with a secid
+ * @secid: an integer that might be associated with a Smack label
+ *
+ * Returns a pointer to the appropraite Smack label if there is one,
+ * otherwise a pointer to the invalid Smack label.
+ */
+char *smack_from_secid(const u32 secid)
+{
+	struct smack_known *skp;
+
+	for (skp = smack_known; skp != NULL; skp = skp->smk_next)
+		if (skp->smk_secid == secid)
+			return skp->smk_known;
+
+	/*
+	 * If we got this far someone asked for the translation
+	 * of a secid that is not on the list.
+	 */
+	return smack_known_invalid.smk_known;
+}
+
+u32 smack_to_secid(const char *smack)
+{
+	struct smack_known *skp;
+
+	for (skp = smack_known; skp != NULL; skp = skp->smk_next)
+		if (skp->smk_known == smack)
+			return skp->smk_secid;
+	return 0;
+}
+
+/**
+ * smack_from_cipso - find the Smack label associated with a CIPSO option
+ * @level: Bell & LaPadula level from the network
+ * @catset: Bell & LaPadula categories from the network
+ * @result: where to put the Smack value
+ *
+ * This is a simple lookup in the label table.
+ *
+ * This is an odd duck as far as smack handling goes in that
+ * it sends back a copy of the smack label rather than a pointer
+ * to the master list. This is done because it is possible for
+ * a foreign host to send a smack label that is new to this
+ * machine and hence not on the list. That would not be an
+ * issue except that adding an entry to the master list can't
+ * be done at that point.
+ */
+void smack_from_cipso(u32 level, char *catset, char *result)
+{
+	struct smack_known *kp;
+	char *final = NULL;
+
+	for (kp = smack_known; final == NULL && kp != NULL; kp = kp->smk_next) {
+		if (kp->smk_cipso == NULL)
+			continue;
+
+		spin_lock_bh(&kp->smk_cipsolock);
+
+		if (kp->smk_cipso->smk_level == level &&
+		    memcmp(kp->smk_cipso->smk_catset,catset,SMK_LABELLEN) == 0)
+			final = kp->smk_known;
+
+		spin_unlock_bh(&kp->smk_cipsolock);
+	}
+	if (final == NULL)
+		final = smack_known_huh.smk_known;
+	strncpy(result, final, SMK_MAXLEN);
+	return;
+}
+
+/**
+ * smack_to_cipso - find the CIPSO option to go with a Smack label
+ * @smack: a pointer to the smack label in question
+ * @cp: where to put the result
+ *
+ * Returns zero if a value is available, non-zero otherwise.
+ */
+int smack_to_cipso(const char *smack, struct smack_cipso *cp)
+{
+        struct smack_known *kp;
+
+	for (kp = smack_known; kp != NULL; kp = kp->smk_next)
+		if (kp->smk_known == smack ||
+		    strcmp(kp->smk_known, smack) == 0)
+			break;
+
+	if (kp == NULL || kp->smk_cipso == NULL)
+		return -ENOENT;
+	
+	memcpy(cp, kp->smk_cipso, sizeof(struct smack_cipso));
+	return 0;
+}

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/smack/smackfs.c linux-2.6.23-rc8-smack/security/smack/smackfs.c

security/smack/smackfs.c +235 -0

@@ -0,0 +1,1201 @@
+/*
+ * Copyright (C) 2007 Casey Schaufler <[email protected]>
+ *
+ *	This program is free software; you can redistribute it and/or modify
+ *  	it under the terms of the GNU General Public License as published by
+ *	the Free Software Foundation, version 2.
+ *
+ * Author:
+ * 	Casey Schaufler <[email protected]>
+ * 
+ * Special thanks to the authors of selinuxfs.
+ * 
+ *	Karl MacMillan <[email protected]>
+ *	James Morris <[email protected]>
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/vmalloc.h>
+#include <linux/security.h>
+#include <linux/mutex.h>
+#include <net/netlabel.h>
+/*
+ * This include could get changed when the internal
+ * netlabel interface for initializing a netlabel domain
+ * has been worked out.
+ */
+#include "netlabel_domainhash.h"
+#include <net/cipso_ipv4.h>
+#include "smack.h"
+
+extern struct mutex smack_list_lock;
+extern struct smack_known smack_known_floor;
+extern struct smack_known smack_known_star;
+extern struct smack_known *smack_known;
+
+/*
+ * smackfs pseudo filesystem.
+ */
+
+enum smk_inos {
+	SMK_ROOT_INO	= 2,
+	SMK_LOAD	= 3,	/* load policy */
+	SMK_LINKS	= 4,	/* symlinks */
+	SMK_CIPSO	= 5,	/* load label -> CIPSO mapping */
+	SMK_DOI		= 6,	/* CIPSO DOI */
+	SMK_DIRECT	= 7,	/* CIPSO level indicating direct label */
+	SMK_AMBIENT	= 8,	/* internet ambient label */
+	SMK_NLTYPE	= 9,	/* label scheme to use by default */
+	SMK_TMP		= 100,	/* MUST BE LAST! /smack/tmp */
+};
+
+/*
+ * This is the "ambient" label for network traffic.
+ * If it isn't somehow marked, use this.
+ * It can be reset via smackfs/ambient
+ */
+char *smack_net_ambient = smack_known_floor.smk_known;
+
+/*
+ * This is the default packet marking scheme for network traffic.
+ * It can be reset via smackfs/nltype
+ */
+int smack_net_nltype = NETLBL_NLTYPE_CIPSOV4;
+
+/*
+ * This is the level in a CIPSO header that indicates a
+ * smack label is contained directly in the category set.
+ * It can be reset via smackfs/direct
+ */
+int smack_cipso_direct = SMACK_CIPSO_DIRECT_DEFAULT;
+
+static int smk_cipso_doi_value = SMACK_CIPSO_DOI_DEFAULT;
+static int smack_list_count;
+struct smk_list_entry *smack_list;
+
+/*
+ * 'ssssssss oooooooo mmmm\n\0' 
+ */
+#define SMACK_RULE_LINE_SIZE (2 * SMK_MAXLEN + 6)
+
+/**
+ * smk_read_load - read() for /smack/load
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_load(struct file *filp, char __user *buf,
+			     size_t count, loff_t *ppos)
+{
+	ssize_t bytes;
+	struct smk_list_entry *slp = smack_list;
+	struct smack_rule *srp;
+	char *result;
+	char *cp;
+	int realbytes = 0;
+	
+	bytes = SMACK_RULE_LINE_SIZE * smack_list_count;
+	if (bytes == 0)
+		return 0;
+
+	result = kzalloc(bytes, GFP_KERNEL);
+	if (result == NULL)
+		return -ENOMEM;
+
+	for (cp = result; slp != NULL; slp = slp->smk_next) {
+		srp = &slp->smk_rule;
+		sprintf(cp, "%-8s %-8s",
+			(char *)srp->smk_subject, (char *)srp->smk_object);
+		cp += strlen(cp);
+		if (srp->smk_access != 0) 
+			*cp++ = ' ';
+		if ((srp->smk_access & MAY_READ) != 0)
+			*cp++ = 'r';
+		if ((srp->smk_access & MAY_WRITE) != 0)
+			*cp++ = 'w';
+		if ((srp->smk_access & MAY_EXEC) != 0)
+			*cp++ = 'x';
+		if ((srp->smk_access & MAY_APPEND) != 0)
+			*cp++ = 'a';
+		*cp++ = '\n';
+	}
+	*cp++ = '\0';
+	realbytes = strlen(result);
+
+	bytes = simple_read_from_buffer(buf, count, ppos, result, realbytes);
+	
+	kfree(result);
+
+	return bytes;
+}
+
+/**
+ * smk_set_access - add a rule to the rule list
+ * @srp: the new rule to add
+ *
+ * Looks through the current subject/object/access list for
+ * the subject/object pair and replaces the access that was
+ * there. If the pair isn't found add it with the specified
+ * access.
+ */
+static void smk_set_access(struct smack_rule *srp)
+{
+	struct smk_list_entry *sp;
+	struct smk_list_entry *newp;
+
+	mutex_lock(&smack_list_lock);
+
+	for (sp = smack_list; sp != NULL; sp = sp->smk_next)
+		if (sp->smk_rule.smk_subject == srp->smk_subject &&
+		    sp->smk_rule.smk_object == srp->smk_object) {
+			sp->smk_rule.smk_access = srp->smk_access;
+			break;
+		}
+
+	if (sp == NULL) {
+		newp = kzalloc(sizeof(struct smk_list_entry), GFP_KERNEL);
+		newp->smk_rule = *srp;
+		newp->smk_next = smack_list;
+		smack_list = newp;
+		smack_list_count++;
+	}
+
+	mutex_unlock(&smack_list_lock);
+
+	return;
+}
+
+
+/**
+ * smk_write_load - write() for /smack/load
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_load(struct file *file, const char __user *buf,
+			      size_t count, loff_t *ppos)
+{
+	struct smack_rule rule;
+	ssize_t rc = count;
+	char *data = NULL;
+	char subjectstr[SMK_LABELLEN];
+	char objectstr[SMK_LABELLEN];
+	char modestr[8];
+	char *cp;
+
+
+	if (!capable(CAP_MAC_OVERRIDE))
+		return -EPERM;
+	/*
+	 * No partial writes.
+	 */
+	if (*ppos != 0)
+		return -EINVAL;
+
+	/*
+	 * 80 characters per line ought to be enough.
+	 */
+	if (count > SMACK_LIST_MAX * 80)
+		return -ENOMEM;
+
+	data = kzalloc(count + 1, GFP_KERNEL);
+	if (data == NULL)
+		return -ENOMEM;
+
+	if (copy_from_user(data, buf, count) != 0) {
+		kfree(data);
+		return -EFAULT;
+	}
+
+	*(data + count) = '\0';
+
+	for (cp = data - 1; cp != NULL; cp = strchr(cp + 1, '\n')) {
+		if (*++cp == '\0')
+			break;
+		if (sscanf(cp, "%23s %23s %7s\n", subjectstr, objectstr,
+			   modestr) != 3) {
+			printk("%s:%d bad scan\n", __func__, __LINE__);
+			break;
+		}
+		rule.smk_subject = smk_import(subjectstr, 0);
+		if (rule.smk_subject == NULL)
+			break;
+		rule.smk_object = smk_import(objectstr, 0);
+		if (rule.smk_object == NULL)
+			break;
+		rule.smk_access = 0;
+		if (strpbrk(modestr, "rR") != NULL)
+			rule.smk_access |= MAY_READ;

security/smack/smackfs.c +956 -0

+	}
+
+	kfree(data);
+	return rc;
+}
+
+static const struct file_operations smk_load_ops = {
+	.read		= smk_read_load,
+	.write		= smk_write_load,
+};
+
+/**
+ * smk_digit - return a pointer to the next digit
+ * @cp: where to start
+ *
+ * Returns a pointer to the next digit in the string, or NULL
+ */
+static inline char *smk_digit(const char *cp)
+{
+	return strpbrk(cp, "0123456789");
+}
+
+static unsigned int smk_cipso_written;
+
+/**
+ * smk_cipso_doi - initialize the CIPSO domain
+ *
+ * This code reaches too deeply into netlabel internals
+ * for comfort, however there is no netlabel KAPI that
+ * allows for kernel based initialization of a CIPSO DOI.
+ * Until Paul and Casey can work out an appropriate
+ * interface Smack will do it this way.
+ */
+void smk_cipso_doi(void)
+{
+	int rc;
+	struct cipso_v4_doi *doip;
+	struct netlbl_dom_map *ndmp;
+	struct netlbl_audit audit_info;
+
+	doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
+	if (doip == NULL)
+		panic("smack:  Failed to initialize cipso DOI.\n");
+	doip->map.std = NULL;
+
+	ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
+	if (ndmp == NULL)
+		panic("smack:  Failed to initialize cipso ndmp.\n");
+
+	doip->doi = smk_cipso_doi_value;
+	doip->type = CIPSO_V4_MAP_PASS;
+	doip->tags[0] = CIPSO_V4_TAG_RBITMAP;
+	for (rc = 1; rc < CIPSO_V4_TAG_MAXCNT; rc++)
+		doip->tags[rc] = CIPSO_V4_TAG_INVALID;
+
+	rc = cipso_v4_doi_add(doip);
+	if (rc != 0)
+		printk("%s:%d add doi rc = %d\n", __func__, __LINE__, rc);
+
+	ndmp->domain = NULL;
+	ndmp->type = NETLBL_NLTYPE_CIPSOV4;
+	ndmp->type_def.cipsov4 = doip;
+
+	rc = netlbl_domhsh_remove_default(&audit_info);
+	if (rc != 0)
+		printk("%s:%d remove rc = %d\n", __func__, __LINE__, rc);
+
+	rc = netlbl_domhsh_add_default(ndmp, &audit_info);
+	if (rc != 0)
+		printk("%s:%d add rc = %d\n", __func__, __LINE__, rc);
+}
+
+/**
+ * smk_read_cipso - read() for /smack/cipso
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ *
+ * label level[/cat[,cat]]
+ */
+static ssize_t smk_read_cipso(struct file *filp, char __user *buf,
+			      size_t count, loff_t *ppos)
+{
+	struct smack_known *skp;
+	struct smack_cipso *scp;
+	ssize_t bytes;
+	char sep;
+	char *result;
+	char *cp;
+	char *cbp;
+	int realbytes = 0;
+	int cat = -1;
+	int i;
+	unsigned char m;
+
+	if (smk_cipso_written == 0)
+		return 0;
+
+	result = kzalloc(smk_cipso_written, GFP_KERNEL);
+	if (result == NULL)
+		return -ENOMEM;
+	cp = result;
+
+	for (skp = smack_known; skp != NULL; skp = skp->smk_next) {
+		if (skp->smk_cipso == NULL)
+			continue;
+		scp = skp->smk_cipso;
+		cp += sprintf(cp, "%-8s %3d",
+			(char *)&skp->smk_known, scp->smk_level);
+		cat = 1;
+		sep = '/';
+		cbp = scp->smk_catset;
+		for (i = 0; i < SMK_LABELLEN; i++) {
+			for (m = 0x80; m != 0; m >>= 1) {
+				if ((m & cbp[i]) != 0) {
+					cp += sprintf(cp, "%c%d", sep, cat);
+					sep = ',';
+				}
+				cat++;
+			}
+		}
+		*cp++ = '\n';
+	}
+	*cp++ = '\0';
+	realbytes = strlen(result);
+
+	bytes = simple_read_from_buffer(buf, count, ppos, result, realbytes);
+	
+	kfree(result);
+
+	return bytes;
+}
+
+/**
+ * smk_write_cipso - write() for /smack/cipso
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_cipso(struct file *file, const char __user *buf,
+			       size_t count, loff_t *ppos)
+{
+	struct smack_known *skp;
+	struct smack_cipso *scp;
+	char *mapsmack;
+	char mapcatset[SMK_LABELLEN];
+	int maplevel;
+	ssize_t rc = count;
+	char *data = NULL;
+	char *cp;
+	char *eolp;
+	char *linep;
+	int cat;
+	int i;
+
+	if (!capable(CAP_MAC_OVERRIDE))
+		return -EPERM;
+	/*
+	 * No partial writes.
+	 */
+	if (*ppos != 0)
+		return -EINVAL;
+	/*
+	 * 80 characters per line ought to be enough.
+	 */
+	if (count > SMACK_LIST_MAX * 80)
+		return -ENOMEM;
+
+	data = kzalloc(count + 1, GFP_KERNEL);
+	if (data == NULL)
+		return -ENOMEM;
+
+	if (copy_from_user(data, buf, count) != 0) {
+		kfree(data);
+		return -EFAULT;
+	}
+
+	*(data + count) = '\0';
+	smk_cipso_written += count;
+
+	for (eolp = strchr(data, '\n'), linep = data;
+		eolp != NULL && rc >= 0;
+		linep = eolp + 1, eolp = strchr(linep, '\n')) {
+
+		if (eolp == linep)
+			continue;
+		*eolp = '\0';
+		memset(mapcatset, '\0', SMK_LABELLEN);
+
+		skp = smk_import_entry(linep, 0);
+		if (skp == NULL)
+			continue;
+		mapsmack = skp->smk_known;
+
+		cp = smk_digit(linep + strlen((char *)mapsmack));
+		if (cp == NULL)
+			continue;
+
+		i = sscanf(cp, "%d", &maplevel);
+		if (i != 1)
+			continue;
+
+		cp = strchr(cp, '/');
+		if (cp != NULL) {
+			cp = smk_digit(cp);
+			if (cp == NULL)
+				continue;
+
+			do {
+				i = sscanf(cp, "%d", &cat);
+				if (i != 1)
+					break;
+				if (cat > SMACK_CIPSO_MAXCAT) {
+					i = 0;
+					break;
+				}
+				smack_catset_bit(cat, mapcatset);
+
+				cp = strchr(cp, ',');
+				if (cp != NULL)
+					cp = smk_digit(cp);
+			} while (cp != NULL);
+		}
+
+		if (i != 1)
+			continue;
+
+
+		if (skp->smk_cipso == NULL) {
+			scp = kzalloc(sizeof(struct smack_cipso), GFP_KERNEL);
+			if (scp == NULL) {
+				rc = -ENOMEM;
+				break;
+			}
+		} else
+			scp = NULL;
+
+		spin_lock_bh(&skp->smk_cipsolock);
+		if (skp->smk_cipso == NULL) {
+			skp->smk_cipso = scp;
+			scp = NULL;
+		}
+		skp->smk_cipso->smk_level = maplevel;
+		memcpy(skp->smk_cipso->smk_catset, mapcatset, SMK_MAXLEN);
+		spin_unlock_bh(&skp->smk_cipsolock);
+
+		/*
+		 * The only way this could be true is for there
+		 * to have been two attempts to update the cipso
+		 * list at the same time. One of the two will have
+		 * won cleanly, but there remains cleanup to do.
+		 */
+		if (scp != NULL) {
+			printk(KERN_WARNING "%s: CIPSO collision for \"%s\"\n",
+				__func__, skp->smk_known);
+			kfree(scp);
+		}
+		/*
+		 * Add this to ensure that there are
+		 * enough bytes for the regurgitation
+		 */
+		smk_cipso_written += SMK_LABELLEN;
+	}
+
+	kfree(data);
+	return rc;
+}
+
+static const struct file_operations smk_cipso_ops = {
+	.read		= smk_read_cipso,
+	.write		= smk_write_cipso,
+};
+
+/**
+ * smk_read_doi - read() for /smack/doi
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_doi(struct file *filp, char __user *buf,
+			        size_t count, loff_t *ppos)
+{
+	char temp[80];
+	ssize_t rc;
+
+	if (*ppos != 0)
+		return 0;
+
+	sprintf(temp, "%d", smk_cipso_doi_value);
+	rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
+
+	return rc;
+}
+
+/**
+ * smk_write_doi - write() for /smack/doi
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_doi(struct file *file, const char __user *buf,
+			         size_t count, loff_t *ppos)
+{
+	char temp[80];
+	int i;
+
+	if (!capable(CAP_MAC_OVERRIDE))
+		return -EPERM;
+
+	if (count > sizeof(temp))
+		return -EINVAL;
+
+	if (copy_from_user(temp, buf, count) != 0)
+		return -EFAULT;
+
+	if (sscanf(temp, "%d", &i) != 1)
+		return -EINVAL;
+
+	smk_cipso_doi_value = i;
+
+	return count;
+}
+
+static const struct file_operations smk_doi_ops = {
+	.read		= smk_read_doi,
+	.write		= smk_write_doi,
+};
+
+/**
+ * smk_read_direct - read() for /smack/direct
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_direct(struct file *filp, char __user *buf,
+			        size_t count, loff_t *ppos)
+{
+	char temp[80];
+	ssize_t rc;
+
+	if (*ppos != 0)
+		return 0;
+
+	sprintf(temp, "%d", smack_cipso_direct);
+	rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
+
+	return rc;
+}
+
+/**
+ * smk_write_direct - write() for /smack/direct
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_direct(struct file *file, const char __user *buf,
+			         size_t count, loff_t *ppos)
+{
+	char temp[80];
+	int i;
+
+	if (!capable(CAP_MAC_OVERRIDE))
+		return -EPERM;
+
+	if (count > sizeof(temp))
+		return -EINVAL;
+
+	if (copy_from_user(temp, buf, count) != 0)
+		return -EFAULT;
+
+	if (sscanf(temp, "%d", &i) != 1)
+		return -EINVAL;
+
+	smack_cipso_direct = i;
+
+	return count;
+}
+
+static const struct file_operations smk_direct_ops = {
+	.read		= smk_read_direct,
+	.write		= smk_write_direct,
+};
+
+/**
+ * smk_read_ambient - read() for /smack/ambient
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_ambient(struct file *filp, char __user *buf,
+			        size_t count, loff_t *ppos)
+{
+	ssize_t rc;
+	int asize = strlen(smack_net_ambient) + 1;
+
+	if (count < asize)
+		return -EINVAL;
+
+	if (*ppos != 0)
+		return 0;
+
+	rc = simple_read_from_buffer(buf,count,ppos,smack_net_ambient,asize);
+
+	return rc;
+}
+
+/**
+ * smk_write_ambient - write() for /smack/ambient
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_ambient(struct file *file, const char __user *buf,
+			         size_t count, loff_t *ppos)
+{
+	char in[SMK_LABELLEN];
+	char *smack;
+
+	if (!capable(CAP_MAC_OVERRIDE))
+		return -EPERM;
+
+	if (count >= SMK_LABELLEN)
+		return -EINVAL;
+
+	if (copy_from_user(in, buf, count) != 0)
+		return -EFAULT;
+
+	smack = smk_import(in, count);
+	if (smack == NULL)
+		return -EINVAL;
+	/*
+	 * Better check to be sure this is OK.
+	 */
+	smack_net_ambient = smack;
+
+	return count;
+}
+
+static const struct file_operations smk_ambient_ops = {
+	.read		= smk_read_ambient,
+	.write		= smk_write_ambient,
+};
+
+struct option_names {
+	int	o_number;
+	char	*o_name;
+	char	*o_alias;
+};
+
+static struct option_names netlbl_choices[] = {
+	{ NETLBL_NLTYPE_RIPSO,
+		NETLBL_NLTYPE_RIPSO_NAME,	"ripso" },
+	{ NETLBL_NLTYPE_CIPSOV4,
+		NETLBL_NLTYPE_CIPSOV4_NAME,	"cipsov4" },
+	{ NETLBL_NLTYPE_CIPSOV4,
+		NETLBL_NLTYPE_CIPSOV4_NAME,	"cipso" },
+	{ NETLBL_NLTYPE_CIPSOV6,
+		NETLBL_NLTYPE_CIPSOV6_NAME,	"cipsov6" },
+	{ NETLBL_NLTYPE_UNLABELED,
+		NETLBL_NLTYPE_UNLABELED_NAME,	"unlabeled" },
+};
+
+/**
+ * smk_read_nltype - read() for /smack/nltype
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_nltype(struct file *filp, char __user *buf,
+			       size_t count, loff_t *ppos)
+{
+	char bound[40];
+	ssize_t rc;
+	int i;
+
+	if (count < SMK_LABELLEN)
+		return -EINVAL;
+
+	if (*ppos != 0)
+		return 0;
+
+	sprintf(bound, "unknown");
+
+	for (i = 0; i < ARRAY_SIZE(netlbl_choices); i++)
+		if (smack_net_nltype == netlbl_choices[i].o_number) {
+			sprintf(bound, "%s", netlbl_choices[i].o_name);
+			break;
+		}
+
+	rc = simple_read_from_buffer(buf, count, ppos, bound, strlen(bound));
+
+	return rc;
+}
+
+/**
+ * smk_write_nltype - write() for /smack/nltype
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_nltype(struct file *file, const char __user *buf,
+			        size_t count, loff_t *ppos)
+{
+	char bound[40];
+	char *cp;
+	int i;
+
+	if (!capable(CAP_MAC_OVERRIDE))
+		return -EPERM;
+
+	if (count >= 40)
+		return -EINVAL;
+
+	if (copy_from_user(bound, buf, count) != 0)
+		return -EFAULT;
+
+	bound[count] = '\0';
+	cp = strchr(bound, ' ');
+	if (cp != NULL)
+		*cp = '\0';
+	cp = strchr(bound, '\n');
+	if (cp != NULL)
+		*cp = '\0';
+
+	for (i = 0; i < ARRAY_SIZE(netlbl_choices); i++)
+		if (strcmp(bound, netlbl_choices[i].o_name) == 0 ||
+		    strcmp(bound, netlbl_choices[i].o_alias) == 0) {
+			smack_net_nltype = netlbl_choices[i].o_number;
+			return count;
+		}
+	/*
+	 * Not a valid choice.
+	 */
+	return -EINVAL;
+}
+
+static const struct file_operations smk_nltype_ops = {
+	.read		= smk_read_nltype,
+	.write		= smk_write_nltype,
+};
+
+/*
+ * mapping for symlinks
+ */
+#define SMK_TMPPATH_SIZE        1024
+#define SMK_TMPPATH_ROOT        "/moldy/"
+
+struct smk_link {
+	struct smk_link	*sl_next;
+	int		sl_inum;
+	char		sl_name[SMK_TMPPATH_SIZE];
+	char		sl_target[SMK_TMPPATH_SIZE];
+};
+
+static struct super_block *smk_sb = NULL;
+static struct smk_link *smk_links = NULL;
+static int smk_links_count = 0;
+
+/**
+ * smackfs_follow_link - follow a smackfs symlink
+ * @dentry: name cache entry
+ * @nd: name entry
+ *
+ * A symlink on smackfs has unusual semantics.
+ *
+ * The Smack value of the task is appended to the link string.
+ * Thus, if a task labeled "Gentoo" does chdir("/smack/tmp")
+ * it will use "/moldy/Gentoo".
+ *
+ * The expected usage is the /tmp is a symlink to /smack/tmp
+ * which is itself a symlink to /moldy. /moldy should have a
+ * directory for each label in use to accomodate the value
+ * appended on the redirection.
+ *
+ * An interesting addition would be a file system that automatically
+ * creates directories as needed, at the appropriate label.
+ */
+static void *smackfs_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
+	char *sp = current->security;
+	char *cp;
+	int inum = dentry->d_inode->i_ino;
+	struct smk_link *slp;
+
+	for (slp = smk_links; slp != NULL; slp = slp->sl_next)
+		if (slp->sl_inum == inum)
+			break;
+
+	if (slp == NULL) {
+		printk("%s:%d failed\n", __func__, __LINE__);
+		return NULL;
+	}
+	cp = kzalloc(SMK_TMPPATH_SIZE, GFP_KERNEL);
+	if (cp == NULL)
+		return NULL;
+
+	strcpy(cp, slp->sl_target);
+	strcat(cp, sp);
+	nd_set_link(nd, cp);
+	/*
+	 * Unlike the readlink below, hang on to the memory allocated
+	 * because nd_set_link passes it along.
+	 */
+	return NULL;
+}
+
+/**
+ * smackfs_readlink - read a smackfs symlink
+ * @dentry: name cache entry
+ * @buffer: where the result goes
+ * @buflen: buffer size
+ *
+ * Returns 0 on success, an error code otherwise
+ *
+ * Supports the same semantics as the follow code.
+ */
+static int smackfs_readlink(struct dentry *dentry, char __user *buffer,
+			    int buflen)
+{
+	char *csp = current->security;
+	char *cp;
+	int len;
+	int inum = dentry->d_inode->i_ino;
+	struct smk_link *slp;
+
+	for (slp = smk_links; slp != NULL; slp = slp->sl_next)
+		if (slp->sl_inum == inum)
+			break;
+
+	if (slp == NULL) {
+		printk("%s:%d failed\n", __func__, __LINE__);
+		return -EACCES;
+	}
+
+	cp = kzalloc(SMK_TMPPATH_SIZE, GFP_KERNEL);
+	if (cp == NULL)
+		return -ENOMEM;
+
+	strcpy(cp, slp->sl_target);
+	strcat(cp, csp);
+	len = strlen(cp);
+	len = (len > buflen) ? buflen : len;
+
+	if (copy_to_user(buffer, cp, len) != 0)
+		len = -EFAULT;
+
+	kfree(cp);
+	return len;
+}
+
+/**
+ * smackfs_put_link - free a followed component
+ * @dentry: unused
+ * @nd: name entry
+ * @ptr: unused
+ *
+ * free the buffer used in following the link.
+ */
+static void smackfs_put_link(struct dentry *dentry, struct nameidata *nd, void *ptr)
+{
+	kfree(nd_get_link(nd));
+}
+
+static struct inode_operations smackfs_symlink_inode_operations = {
+	.readlink	= smackfs_readlink,
+	.follow_link	= smackfs_follow_link,
+	.put_link	= smackfs_put_link,
+};
+
+/**
+ * smk_add_symlink - follow a smackfs symlink
+ * @name: the name of the synlink
+ * @target: where it points to
+ *
+ * Add a smackfs symlink
+ */
+static void smk_add_symlink(char *name, char *target)
+{
+	static int inum = SMK_TMP;
+	struct inode *inode;
+	struct dentry *dentry;
+	struct smk_link *slp;
+
+	for (slp = smk_links; slp != NULL; slp = slp->sl_next) {
+		if (strcmp(slp->sl_name, name) != 0)
+			continue;
+		strcpy(slp->sl_target, target);
+		return;
+	}
+
+	slp = kzalloc(sizeof(struct smk_link), GFP_KERNEL);
+	if (slp == NULL)
+		return;
+
+	dentry = d_alloc_name(smk_sb->s_root, name);
+	if (dentry == NULL) {
+		printk("%s:%d link dentry failed\n", __func__, __LINE__);
+		return;
+	}
+
+	inode = new_inode(smk_sb);
+	if (inode == NULL) {
+		printk("%s:%d link inode failed\n", __func__, __LINE__);
+		return;
+	}
+
+	inode->i_mode = S_IFLNK | S_IRWXUGO;
+	inode->i_uid = 0;
+	inode->i_gid = 0;
+	inode->i_blocks = 0;
+	inode->i_atime = CURRENT_TIME;
+	inode->i_mtime = inode->i_atime;
+	inode->i_ctime = inode->i_atime;
+	inode->i_ino = inum++;
+	inode->i_op = &smackfs_symlink_inode_operations;
+	d_add(dentry, inode);
+
+	strcpy(slp->sl_name, name);
+	strcpy(slp->sl_target, target);
+	slp->sl_inum = inode->i_ino;
+	slp->sl_next = smk_links;
+	smk_links = slp;
+	smk_links_count++;
+
+	return;
+}
+
+/**
+ * smk_read_links - read() for /smack/links
+ * @filp: file pointer, not actually used
+ * @buf: where to put the result
+ * @count: maximum to send along
+ * @ppos: where to start
+ *
+ * Returns number of bytes read or error code, as appropriate
+ */
+static ssize_t smk_read_links(struct file *filp, char __user *buf,
+			     size_t count, loff_t *ppos)
+{
+	ssize_t bytes = sizeof(struct smk_link) * smk_links_count;
+	struct smk_link *slp;
+	char *result;
+	char *cp;
+	
+
+	result = kzalloc(bytes, GFP_KERNEL);
+	if (result == NULL)
+		return -ENOMEM;
+	*result = '\0';
+
+	for (slp = smk_links, cp = result; slp != NULL; slp = slp->sl_next)
+		cp += sprintf(cp, "%s %s\n", slp->sl_name, slp->sl_target);
+
+	bytes = simple_read_from_buffer(buf,count,ppos,result,strlen(result));
+	
+	kfree(result);
+
+	return bytes;
+}
+
+/**
+ * smk_write_links - write() for /smack/links
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Returns number of bytes written or error code, as appropriate
+ *
+ * This might be better done using "real" symlink creation.
+ */
+static ssize_t smk_write_links(struct file *file, const char __user *buf,
+			      size_t count, loff_t *ppos)
+{
+	ssize_t rc = count;
+	char *data;
+	char *cp;
+	char name[SMK_TMPPATH_SIZE];
+	char target[SMK_TMPPATH_SIZE];
+
+	/*
+	 * No partial writes.
+	 */
+	if (*ppos != 0)
+		return -EINVAL;
+	/*
+	 * 80 characters per line ought to be enough.
+	 */
+	if (count > SMACK_LIST_MAX * 80)
+		return -ENOMEM;
+
+	data = kzalloc(count + 1, GFP_KERNEL);
+	if (data == NULL)
+		return -ENOMEM;
+
+	if (copy_from_user(data, buf, count) != 0) {
+		kfree(data);
+		return -EFAULT;
+	}
+
+	data[count] = '\0';
+
+	for (cp = data - 1; cp != NULL; cp = strchr(cp + 1, '\n')) {
+		if (*++cp == '\0')
+			break;
+		if (sscanf(cp, "%14s %30s\n", name, target) != 2) {
+			printk("%s:%d bad scan\n",
+				__func__, __LINE__);
+			break;
+		}
+		smk_add_symlink(name, target);
+		printk("%s:%d add %s -> %s\n",
+			__func__, __LINE__, name, target);
+	}
+
+	kfree(data);
+	return rc;
+}
+
+static const struct file_operations smk_links_ops = {
+	.read		= smk_read_links,
+	.write		= smk_write_links,
+};
+
+/**
+ * smk_fill_super - fill the /smackfs superblock
+ * @sb: the empty superblock
+ * @data: unused
+ * @silent: unused
+ *
+ * Fill in the well known entries for /smack and set up for
+ * symlinks
+ *
+ * Returns 0 on success, an error code on failure
+ */
+static int smk_fill_super(struct super_block *sb, void * data, int silent)
+{
+	int rc;
+	struct inode *root_inode;
+
+	static struct tree_descr smack_files[] = {
+		[SMK_LOAD]	= {"load", &smk_load_ops, S_IRUGO|S_IWUSR},
+		[SMK_LINKS]	= {"links", &smk_links_ops, S_IRUGO|S_IWUSR},
+		[SMK_CIPSO]	= {"cipso", &smk_cipso_ops, S_IRUGO|S_IWUSR},
+		[SMK_DOI]	= {"doi", &smk_doi_ops, S_IRUGO|S_IWUSR},
+		[SMK_DIRECT]	= {"direct", &smk_direct_ops, S_IRUGO|S_IWUSR},
+		[SMK_AMBIENT]	= {"ambient", &smk_ambient_ops,S_IRUGO|S_IWUSR},
+		[SMK_NLTYPE]	= {"nltype", &smk_nltype_ops, S_IRUGO|S_IWUSR},
+		/* last one */ {""}
+	};
+
+	/*
+	 * There will be only one smackfs. Casey says so.
+	 */
+	smk_sb = sb;
+
+	rc = simple_fill_super(sb, SMACK_MAGIC, smack_files);
+	if (rc != 0) {
+		printk(KERN_ERR "%s failed %d while creating inodes\n",
+			__func__, rc);
+		return rc;
+	}
+
+	root_inode = sb->s_root->d_inode;
+	root_inode->i_security = new_inode_smack(smack_known_floor.smk_known);
+
+	/*
+	 * Create a directory for /smack/tmp
+	 */
+	smk_add_symlink("tmp", SMK_TMPPATH_ROOT);
+
+	return 0;
+}
+
+/**
+ * smk_get_sb - get the smackfs superblock
+ * @fs_type: passed along without comment
+ * @flags: passed along without comment
+ * @dev_name: passed along without comment
+ * @data: passed along without comment
+ * @mnt: passed along without comment
+ *
+ * Just passes everything along.
+ *
+ * Returns what the lower level code does.
+ */
+static int smk_get_sb(struct file_system_type *fs_type,
+		      int flags, const char *dev_name, void *data,
+		      struct vfsmount *mnt)
+{
+	return get_sb_single(fs_type, flags, data, smk_fill_super, mnt);
+}
+
+static struct file_system_type smk_fs_type = {
+	.name		= "smackfs",
+	.get_sb		= smk_get_sb,
+	.kill_sb	= kill_litter_super,
+};
+
+static struct vfsmount *smackfs_mount;
+
+/**
+ * init_smk_fs - get the smackfs superblock
+ *
+ * register the smackfs
+ *
+ * Returns 0 unless the registration fails.
+ */
+static int __init init_smk_fs(void)
+{
+	int err;
+
+	err = register_filesystem(&smk_fs_type);
+	if (!err) {
+		smackfs_mount = kern_mount(&smk_fs_type);
+		if (IS_ERR(smackfs_mount)) {
+			printk(KERN_ERR "smackfs:  could not mount!\n");
+			err = PTR_ERR(smackfs_mount);
+			smackfs_mount = NULL;
+		}
+	}
+
+	return err;
+}
+
+__initcall(init_smk_fs);

diff -uprN -X linux-2.6.23-rc8-base/Documentation/dontdiff linux-2.6.23-rc8-base/security/smack/smack.h linux-2.6.23-rc8-smack/security/smack/smack.h

security/smack/smack.h +150 -0

@@ -0,0 +1,207 @@
+/*
+ * Copyright (C) 2007 Casey Schaufler <[email protected]>
+ *
+ *      This program is free software; you can redistribute it and/or modify
+ *      it under the terms of the GNU General Public License as published by
+ *      the Free Software Foundation, version 2.
+ *
+ * Author:
+ *      Casey Schaufler <[email protected]>
+ *
+ */
+
+#ifndef _SECURITY_SMACK_H
+#define _SECURITY_SMACK_H
+
+#include <linux/capability.h>
+#include <linux/spinlock.h>
+#include <net/netlabel.h>
+
+/*
+ * Why 23? CIPSO is constrained to 30, so a 32 byte buffer is
+ * bigger than can be used, and 24 is the next lower multiple
+ * of 8, and there are too many issues if there isn't space set
+ * aside for the terminating null byte.
+ */
+#define SMK_MAXLEN	23
+#define SMK_LABELLEN	(SMK_MAXLEN+1)
+
+struct superblock_smack {
+	char	*smk_root;
+	char	*smk_floor;
+	char	*smk_hat;
+	char	*smk_default;
+	int	smk_initialized;
+};
+
+struct socket_smack {
+	char	*smk_out;	/* outbound label */
+	char	*smk_in;	/* inbound label */
+	char	smk_packet[SMK_LABELLEN];
+	int	smk_depth;
+};
+
+/*
+ * Inode smack data
+ */
+struct inode_smack {
+	char		*smk_inode;	/* label of the fso */
+	struct mutex	smk_lock;	/* initialization lock */
+	int		smk_flags;	/* smack inode flags */
+};
+
+#define	SMK_INODE_INSTANT	0x01	/* inode is instantiated */
+
+/*
+ * A label access rule.
+ */
+struct smack_rule {
+	char	*smk_subject;
+	char	*smk_object;
+	int	smk_access;
+};
+
+/*
+ * An entry in the table of permitted label accesses.
+ */
+struct smk_list_entry {
+	struct smk_list_entry	*smk_next;
+	struct smack_rule	smk_rule;
+};
+
+/*
+ * An entry in the table mapping smack values to
+ * CIPSO level/category-set values.
+ */
+struct smack_cipso {
+	int	smk_level;
+	char	smk_catset[SMK_LABELLEN];
+};
+
+/*
+ * This is the repository for labels seen so that it is
+ * not necessary to keep allocating tiny chuncks of memory
+ * and so that they can be shared.
+ *
+ * Labels are never modified in place. Anytime a label
+ * is imported (e.g. xattrset on a file) the list is checked
+ * for it and it is added if it doesn't exist. The address
+ * is passed out in either case. Entries are added, but
+ * never deleted.
+ *
+ * Since labels are hanging around anyway it doesn't
+ * hurt to maintain a secid for those awkward situations
+ * where kernel components that ought to use LSM independent
+ * interfaces don't. The secid should go away when all of
+ * these components have been repaired.
+ *
+ * If there is a cipso value associated with the label it
+ * gets stored here, too. This will most likely be rare as
+ * the cipso direct mapping in used internally.
+ */
+struct smack_known {
+	struct smack_known	*smk_next;
+	char			smk_known[SMK_LABELLEN];
+	u32			smk_secid;
+	struct smack_cipso	*smk_cipso;
+	spinlock_t		smk_cipsolock;
+};
+
+/*
+ * Mount options
+ */
+#define SMK_FSDEFAULT	"smackfsdef="
+#define SMK_FSFLOOR	"smackfsfloor="
+#define SMK_FSHAT	"smackfshat="
+#define SMK_FSROOT	"smackfsroot="
+
+/*
+ * xattr names
+ */
+#define XATTR_SMACK_SUFFIX	"SMACK64"
+#define XATTR_SMACK_IPIN	"SMACK64IPIN"
+#define XATTR_SMACK_IPOUT	"SMACK64IPOUT"
+#define XATTR_SMACK_PACKET	"SMACK64PACKET"
+#define XATTR_NAME_SMACK	XATTR_SECURITY_PREFIX XATTR_SMACK_SUFFIX
+
+/*
+ * smackfs macic number
+ */
+#define SMACK_MAGIC	0x43415d53 /* "SMAC" */
+
+/*
+ * A limit on the number of entries in the lists
+ * makes some of the list administration easier.
+ */
+#define SMACK_LIST_MAX	10000
+
+/*
+ * CIPSO defaults.
+ */
+#define SMACK_CIPSO_DOI_DEFAULT		3	/* Historical */
+#define SMACK_CIPSO_DIRECT_DEFAULT	250	/* Arbitrary */
+#define SMACK_CIPSO_MAXCAT		63	/* Bigger gets harder */
+
+/*
+ * Just to make the common cases easier to deal with
+ */
+#define MAY_ANY		(MAY_READ | MAY_WRITE | MAY_APPEND | MAY_EXEC)
+#define MAY_ANYREAD	(MAY_READ | MAY_EXEC)
+#define MAY_ANYWRITE	(MAY_WRITE | MAY_APPEND)