login
Search
From: Casey Schaufler <casey@schaufler-ca.com>
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other tasks. Smack is a kernel based scheme that requires
an absolute minimum of application support and a very small
amount of configuration data.
Smack is implemented as a clean LSM. It requires no external
code changes and the patch modifies only the Kconfig and Makefile
in the security directory. Smack uses extended attributes and
provides a set of general mount options, borrowing technics used
elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
a pseudo-filesystem smackfs that is used for manipulation of
system Smack attributes.
The patch, patches for ls and sshd, a README, a startup script,
and x86 binaries for ls and sshd are also available on
http:/www.schaufler-ca.com
The patch has been tested with 2.6.22, 2.6.23-rc8, and
2.6.23-rc8-mm2. Development has been done using Fedora Core 7
in a virtual machine environment and on an old Sony laptop.
Smack provides mandatory access controls based on the label attached
to a task and the label attached to the object it is attempting to
access. Smack labels are deliberately short (1-23 characters) text
strings. Single character labels using special characters are reserved
for system use. The only operation applied to Smack labels is equality
comparison. No wildcards or expressions, regular or otherwise, are
used.
A file always gets the Smack label of the task that created it.
Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
is permitted.
3. A read or execute access requested on an object ...I don't know enough about security even to be dangerous. I went back and reviewed the August thread from your version 1 submission and the message I take away is that the code has been well-received and looks good when considered on its own merits, but selinux could probably be configured to do something sufficiently similar. I'd have trouble declaring that "but" to be a reason to not merge smack. And that wonderful diffstat really is key to being able to do this. My major non-technical concern is that Casey Schaufler might get hit by a bus. If this happens, we can remove the feature in three minutes (that diffstat again), but that may not be feasible if people have come to rely upon the feature. otoh, if a significant number of people are using smack, presumably someone else would step up to maintain smack post-bus. The risk seems acceptable to me. My major technical concern is the apparent paucity of documentation. So with the information which I presently have available to me, I'm thinking that this should go into 2.6.24. Is smack useful without a patched ls, sshd and init.d? What is the status of getting those userspace patches merged? ie: do you know who to send the diffs to, and are they likely to take them? What other userspace tools are likely to need patching? Notes on the code: - Please run scripts/checkpatch.pl across the diff. It generates 50-100 warnings about minor stylistic matters, and those warnings all look legit to me. (extern decls in C are my fave peeve). - Smack.txt and the website seem a bit skimpy. Is there enough documentation out there for someone to usefully (and, more importantly, safely) start using smack? - In his review of version 1, Andi suggested that your ruleset traversal be protected by RCU. But it seems that this wasn't done. Were the races which he identified fixed by other means? If so, what were they? - hm, netlabels. Who might be a suitable person to review that code? Seems ...
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. -
Paul and I discussed this earlier, and will again. Thank you. Casey Schaufler casey@schaufler-ca.com -
Any rationale for this NACK? Caseys patch doesn't add something crazy like "make symlinks depend on environment variables"; also, we already have something similar in-tree: /proc/self. Thomas -
The issue was moot because rulesets never get removed in the current implementation. I had missed that. If that ever changes RCU would be likely I personally consider these IP options it uses to be pretty useless. Who could ever use that without cryptographic authentication? Clearly when they were designed in the original IP spec long ago the designers didn't understand network security very well because the whole field was at its infancy. And CIPSO doesn't solve any of these fundamental issues. It assumes a trusted network which is a very dangerous assumption. I don't think that was in the original patch I looked at, I surely would have objected to it. Perhaps take the network part out? I guess SMACK would be useful locally even without questionable network support. -Andi -
CIPSO is supported on SELinux as well. It certainly has uses where IPSec is excessive. One example is someone I talked to recently that basically has a set of blade systems connected with a high speed backplane that looks like a network interface. CIPSO is useful in this case because they can't afford the overhead of IPSec but need to transfer the level of the connection to the other machines. The backplane is a trusted network and that isn't a dangerous assumption in this case. CIPSO also lets systems like SELinux and SMACK talk to other trusted systems (eg., trusted solaris) in a way they understand. I don't regularly support CIPSO as I believe IPSec labeling is more useful in more situations but that doesn't mean CIPSO is never useful. -
Security that isn't secure is not really useful. You might as well not bother. -Andi -
As always, it depends on your environment. There are people who are using Linux systems where trusting the network makes sense. For example, if you're on a battleship, say, or all of the machines are in a cluster which is inside a Tempest-shielded machine room with a massive combination lock that you might find on a bank vault, or if you're environment where network cables are protected by pressurized pipes (so any attempt to tamper with or tap the cables causes a pressure drop which sets off the alarm which summons the Marines armed with M-16's...). (I've been inside classified machine rooms, which is why my laptop has the 'Unclassified' label on it; it's needed so people can easily eyeball it and know that I'm not allowed to connect it to any of the classified networks. And those are just the less serious machine rooms. In the really serious classified areas with the bank vault-like doors, and the copper-tinted windows, I'm not allowed to bring in an unclassified laptop at all --- and yes, Linux is being used in such environments. And yes, they do sometimes use IPSO and/or There are different kinds of security. Not all of them involve cryptography and IPSEC. Some of them involve armed soldiers and air gap firewalls. :-) Yes, normally the network is outside the Trusted Computing Base (TCB), but a cluster of Linux machines in a rack is roughly the same size of a huge Unix server tens year ago --- and it's not like Ethernet is any more secure than the PCI bus. So why do we consider communications across a PCI bus secure even though they aren't encrypted? Why, because normally we assume the PCI bus is inside the trust boundary, and so we don't worry about bad guys tapping communications between the CPU and the hard drive on the PCI bus. But these days, it is obviously possible to create clusters where certain network interfaces are only connected to machines contained completely inside the trust boundary, just like a PCI bus in a traditional server. So don't ...
PCI busses normally don't have routers to networks outside the box connected With your argumentation we could also just disable all security in these situations (as in null LSM to save some overhead); after all these systems are protected by armed guards. If someone gets past the guards they could connect their laptop to the network and fake all the "secured" packets. If you assume that won't happen why do you need computer security at all? Anyways; if someone wants to cripple their security for some performance this way they can surely do this; but i don't think we should offer it as a default configuration option (just as we don't have a CONFIG_NULL_LSM even though there are undoubtedly systems that don't care about permission checking[1]) -Andi [1] I bet I gave the linux-tiny crowd an idea now ;-) -
The whole *point* is that the routers are interconnecting boxes inside the cluster, and none of them connect to the outside world. It's no different than a SCSI cable connecting to JBOD in a separate box, or a Fiber Channel router connected to a SAN network connecting to a storrage array. The SCSI or FC buses aren't encrypted either, and the in the Fiber channel case we have a router --- yet people aren't stressing out that we're not encrpying the traffic over the Storage Area Network? Why? Because it's understood the network stays inside the machine room. The same thing can true for Ethernet --- think If you get past all of the guards, you can usually reboot in single user mode, and get root anyway. If you have physical access to the computer, you're generally doomed anyway, unless you are willing to pay the cost of encrypting everything on every single disk platter. (And yes, in the more paranoid environments, where it's too expensive to have 7x24 armed guards, maybe that makes sense.) The point of something like CIPSO is because you want to label the packets so the otherside knows how they should be treated. We don't encrypt unix permission bits on most on-disk filesystems, either. Yet I haven't heard people saying that just because someone could break into a machine room, disconnect the JBOD from the computer, hook up the JBOD to their laptop, and futz with the Unix permission bits, rehook up the JBOD and reboot, that Unix permission bits are useless, and we should leave all files at mode 777 --- since clearly we're not secure against someone who can break into the machine room..... I *hope* that sounds absurd, right? - Ted -
You would need authoritative LSM hooks for this. The current LSM additional restrictions model does not provide for this. Casey Schaufler casey@schaufler-ca.com -
Sorry I'm a bit late to the discussion (been busy doing "weekend" things), but I see that Casey, Josh, and Ted have already given a pretty good explanation of why CIPSO is not as "evil" as it appears at first glance. I won't restate the points they have already made, but I think there are two other points worth mentioning: The first is that CIPSO options are immutable, which means they work wonderfully with IPsec. Label integrity can be provided through the use of AH and/or tunneled ESP, label confidentiality can be provided through tunneled ESP. While the SELinux specific labeled IPsec implementation we currently have in the kernel is nice if you are talking to other SELinux machines, it has a very real handicap in that you can't use it to talk anything else. CIPSO, or CIPSO in combination with standard, non-labeled IPsec, can be used to talk to pretty much any trusted OSs out there. Adherence to standards and interoperability with other OSs have always been a key factor of Linux's acceptance into new areas; support for CIPSO is just another part of this drive for greater interoperability. The second point I wanted to make is that in the course of putting together the CIPSO implementation in the kernel I ended up talking with a few people who were involved in the original TSIG effort and the mess with the IETF. From what I could gather, the main technical complaint (other than a variety of political complaints which aren't relevant to our discussion here) was that CIPSO options are difficult to parse (they are, look at the format - it's an option within an option format - yuck) and the intermediate node vendors did not like it all (too much work to do in a fastpath ASIC). After all, look at the [R]IPSO RFC, dated only eight months earlier, and there is no cryptographic "special sauce" in that protocol. CIPSO isn't for everyone, I'll be the first to admit that. However, if you look at the mailing list archive for the Linux LSPP effort, the ...
Real quickly, CIPSO doesn't try to. CIPSO attaches attribute information to the packet, and that's it. Smack uses CIPSO because it's available and sufficient to get the required information about packets from one task to another inside the box. It does the job going off box, too. That would break sockets. I really doubt that you're suggesting that cryptographic authentication is required on the loopback interface. Casey Schaufler casey@schaufler-ca.com -
It does not as far as I can see. The IETF seems to have had very good First rule of network security: don't trust the network. And you seem to trust your security to the network which is just double plus bogus. Without authentication it's completely useless. I don't understand how you can disregard that as "separate issue". Security is only secure if you plugged all applicable holes; without that it's useless You didn't solve sockets security, so they cannot be really broken. And it's not that network security isn't well understood and well supported in Linux by various proven subsystems (ipsec, netfilter, ssh, openssl etc.). For local communication security there are better options like Unix sockets which can be protected by standard file system protections. And most networking is not over loopback after all. Only handling loopback is so limited that it's bordering to useless. And again we have plenty of proven networking security solutions anyways. They all work fine over loopback too. I don't really see what SMACK can add here. -Andi -
but this is so silly that I have to object. saying that any security short of perfect security is worthless and we shouldn't bother is wrong, and needs to be countered every time it's said. as ted pointed out in response to your other comments, it very much depends on where the trust boundry is. so from the point of view of absolute security you are wrong. but even more then that, the vast majority of the time absolute security isn't what matters, relative security is what matters (the model of "I don't have to outrun the bear, I only have to outrun you") and in these envrionments things that are less then absolute can still be very useful. how useful they are depends on a lot of details, and in the case of the network security being discussed it sure sounds like it's pretty close to useless if you can't trust the network and the other machines on it, but that is seperate from the mentality that "anything less then perfect security is worthless and shouldn't be bothered with" which is what I'm objecting to. David Lang -
I've been leading with code, and working on the documentation Over time the Smack application changes will fairly closely follow those for SELinux, e.g. cron, login, su, the MLS window environment. There won't be a major set of new applications or libraries as there isn't a Paul was the first person to whom I sent the patch. I would be The original intent was an "external" vs "internal" distinction, Thank you. The current set of interfaces and practices make kernel coding much easier than it was back in the Unix days. Casey Schaufler casey@schaufler-ca.com -
Yep, I've been tracking Casey's work on this since the first patch and sending comments when appropriate. I'm going to take a look at the latest rev of the patch and if anything looks awry I'll be sure to let Casey know. The only real wart that still remains from the original patch is the code in smk_cipso_doi() which has a nice comment at the top saying that Paul and Casey need to work out an appropriate interface between NetLabel and SMACK. We punted on it before because SMACK's future was still a bit uncertain and SELinux has no need for an interface like this at present. Now that SMACK looks to be queued up for 2.6.24 it's time to revisit this discussion. -- paul moore linux security @ hp -
I 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 ...
Hell f*cking NO! You security people are insane. I'm tired of this "only my version is correct" crap. The whole and only point of LSM was to get away from that. And anybody who claims that there is "consensus" on SELinux is just in denial. People are arguing against other peoples security on totally bogus points. First it was AppArmor, now this. I guess I have to merge AppArmor and SMACK just to get this *disease* off the table. You're acting like a string theorist, claiming that t here is no other viable theory out there. Stop it. It's been going on for too damn long. Linus -
You argued against pluggable schedulers, right? Why is security different? Do you really want to encourage people to roll their own security module rather than working toward a common security architecture and a single balanced solution (which doesn't necessarily mean SELinux, mind you, but certainly could draw from parts of it)? As with pluggable schedulers, the LSM approach prevents cross pollination and forces users to make poor choices. Some have suggested that security modules are no different than filesystem implementations, but filesystem implementations at least are constrained by their need to present a common API and must conform with and leverage the VFS infrastructure. Different security modules present very different interfaces and behaviors from one another and LSM doesn't provide the same kind of common functionality and well-defined semantics as the VFS. The result of merging many wildly different security modules will be chaos for application developers and users, likely leading them to ignore everything but the least common denominator. It almost makes more sense to merge no security modules at all than to have LSM and many different security modules. If Smack is mergeable despite likely being nothing more than a strict subset of SELinux (MAC, label-based, should be easily emulated on top of SELinux or via fairly simple extension to it to make such emulation simpler or more optimal), then what isn't mergeable as a separate security module? -- Stephen Smalley National Security Agency -
Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is "hard science". The other one is "people wanking around with their opinions". If you guys had been able to argue on hard data and be in agreement, LSM wouldn't have been needed in the first place. BUT THAT WAS NOT THE CASE. And perhaps more importantly: BUT THAT IS *STILL* NOT THE CASE! Another difference is that when it comes to schedulers, I feel like I actually can make an informed decision. Which means that I'm perfectly happy to just make that decision, and take the flak that I get for it. And I do (both decide, and get flak). That's my job. In contrast, when it comes to security, I see people making IDIOTIC arguments, and I absolutely *know* that those arguments are pure and utter crap, and at the same time, I see that those people are supposed to be "experts". For example, you security guys still debate "inodes" vs "pathnames", as if that was an either-or issue. Quite frankly, I'm not a security person, but I can tell a bad argument from a good one. And an argument that says "inodes _or_ pathnames" is so full of shit that it's not even funny. And a person who says that it has to be one or the other is incompetent. Yet that is *still* the level of disagreement I see. So LSM stays in. No ifs, buts, maybes or anything else. When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can I'm simply not interested in this discussion. If you cannot understand the ...
Not so much incompetent as religious fundamentalist. Which is worse. OG. -
And yet you can make the exact same case for schedulers as security, you can quantify the behavior, but if your only choice is A it doesn't help to know that B is better. You say "performance" as if it had universal meaning. In truth people want to optimize for total tps (servers), or responsiveness on the human scale (mail, dns, nntp servers), or perceived smoothness (with many threads updating a display to slow with load rather than start visibly jumping the motion from one to another), or very short term response (-rt patches). People want very different behavior under the same load, and that is what *they* call "performance," namely best delivery of what's important. The numbers are "hard science" but the choice of which numbers are important is still "people wanking around with their opinions". -- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -
You snipped a key part of the argument. Namely: Another difference is that when it comes to schedulers, I feel like I actually can make an informed decision. Which means that I'm perfectly happy to just make that decision, and take the flak that I get for it. And I do (both decide, and get flak). That's my job. which you seem to not have read or understood (neither did apparently Blah. Bogus and pointless argument removed. When it comes to schedulers, "performance" *is* pretty damn well-defined, and has effectively universal meaning. The arguments that "servers" have a different profile than "desktop" is pure and utter garbage, and is perpetuated by people who don't know what they are talking about. The whole notion of "server" and "desktop" scheduling being different is nothing but crap. I don't know who came up with it, or why people continue to feed the insane ideas. Why do people think that servers don't care about latency? Why do people believe that desktop doesn't have multiple processors or through-put intensive loads? Why are people continuing this *idiotic* scheduler discussion? Really - not only is the whole "desktop scheduler" argument totally bogus to begin with (and only brought up by people who either don't know anything about it, or who just want to argue, regardless of whether the argumen is valid or not), quite frankly, when you say that it's the "same issue" as with security models, you're simply FULL OF SH*T. The issue with LSM is that security people simply cannot even agree on the model. It has nothing to do with performance. It's about management, and it's about totally different models. Have you even *looked* at the differences between AppArmor and SELinux? Did you look at SMACK? They are all done by people who are interested in security, but have totally different notions of what "security" even *IS*ALL*ABOUT. In contrast, anybody who claims that the CPU scheduler doesn't know what it's all about is just ...
Btw, one thing that is true: while both servers and desktop cares about latency, it's often easier to *see* the issues on the desktop (or hear them: audio skipping). But that doesn't mean that the server people wouldn't care, and it doesn't mean that scheduling would be "fundamentally different" on servers or the desktop. In contrast, security really *is* fundamentally different in different situations. For example, I find SELinux to be so irrelevant to my usage that I don't use it at all. I just don't have any other users on my machine, so the security I care about is in firewalls etc. And that really *is* fundamentally different from a system that has shell access to its users. Which in turn is fundamentally different from one that has some legal reasons why it needs to have a particular kind of security. Which in turn is fundamentally different from .... You get the idea. It boils down to: "scheduling is scheduling", and doesn't really change apart from the kind of decisions that are required by any scheduler (ie RT vs non-RT etc). Everybody wants the same thing in the end: low latency for loads where that matters, high bandwidth for loads where that matters. It's not a "one user has only one kind of load". Not at all. Security, on the other hand, very much does depend on the circumstances and the wishes of the users (or policy-makers). And if we had one module that everybody would be happy with, I'd not make it pluggable either. But as it is, we _know_ that's not the case. Linus -
That you know about... The value of SELinux (or indeed any system compartmentalising access and limiting damage) comes into play when you get breakage - eg via a web browser exploit. Yes SELinux is much more relevant to servers, and really comes into its own when its used to write custom rulesets and enforce corporate policy ("No you can't run that screensaver that arrived by email"). Alan -
well, being sick of the number of times one has to upgrade the browser for exploits, I addressed it in a different way. I ran firefox setuid to a different (not my main user), uid+gid, gave my main account that gid as a supplemental group, and gave that uid access to the X magic cookie. ... which only changes the nature of any exploit that might occur - any injected code would have to go via X to attack my main account. DF -
You need to use runxas to get any kind of real security. -
Interesting script - sad how everyone reinvents equivalent things. I had been experimenting with running the whole lot under Xnest, with two extra users - one for the Xnest which had the main X cookie, and another for the browser. But found that it was just too awkward (since I use multiple browser windows as well a tabs). So I ended up trading a small security gain vs usablity. The other thing I started playing with was the NX version of Xnest, since it allows for a rootless server... DF -
And you claim you are not a security expert :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work -
Actually I had quoted that, made a reply, and decided that my reply was too close to a flame and deleted the quote and the nasty reply, because I couldn't find a nice way to say what I wanted. Oh well, I tried to keep to a higher level, but... on this topic you seem to be off on an ego trip. You are not the decider, George Bush is the decider, and the only time he's not wrong he didn't understand the question. I checked the schedule, it's not you week to be God. There are sensible people you respect on other topics, who have the opinion that there is room for behaviors other than CFS, and who have created a pluggable scheduler framework which they are trying to hand you on a platter. And you won't even consider that they might be right, because you believe there can be one scheduler which is close to optimal Unfortunately not so, I've been looking at schedulers since MULTICS, and desktops since the 70s (MP/M), and networked servers since I was the ARPAnet technical administrator at GE's Corporate R&D Center. And on desktops response is (and should be king), while on a server, like nntp or mail, I will happily go from 1ms to 10sec for a message to pass through the system if only I can pass 30% more messages per hour, because in virtually all cases transit time in that range is not an issue. Same thing for DNS, LDAP, etc, only smaller time range. If my Because people who run servers for a living, and have to live with limited hardware capacity realize that latency isn't the only issue to be addressed, and that the policy for degradation of latency vs. Because people can't get you to understand that one size doesn't fit all The real issue is that you can't imagine that people who don't share your opinion are not only wrong but don't understand the problem. You may be right, but when you say anyone who disagrees is wrong by definition, then you have lost sight of productive technical differences. When your arguments drop to personal attacks and ...
Bill, that's a *tuning* issue, not a scheduler logic issue. You can do that today. The scheduler has always had (well, *almost* always: I think the really really original one didn't) had tuning knobs. It in no way excuses any "pluggable scheduler", because IT DOES NOT CHANGE THE PROBLEM. [ Side note: not only doesn't it change the problem, but a good scheduler tunes itself rather naturally for most things. In particular, for things that really are CPU-limited, the scheduler should be able to notice that, and will not aim for latency to the same degree. In fact, what is really important is that the scheduler notice that some programs are latency-critical AT THE SAME TIME as other programs sharing that CPU are not, which very much implies that you absolutely MUST NOT have a scheduler that done one or the other: it needs to know about *both* behaviors at the same time. IOW, it is very much *not* about multiple different "pluggable modules", because the scheduler must be able to work *across* these kinds of barriers. ] So for example, with the current scheduler, you can actually set things like scheduler latency. Exactly so you can tune things. However, I actually would argue that you generally shouldn't need to, and if you really do need to, and it's a huge deal for a real load (and not just a few percent for a benchmark), we should consider that a scheduler problem. So your "argument" is nonsense. You're arguing for something else than what you _claim_ to be arguing for. What you state that you want actually has nothing what-so-ever to do with pluggable schedulers, quite the reverse! It's also totally incorrect to state that this is somehow intrisicly a feature of a "server load". Many server loads have very real latency constraints. No, not the traditional UNIX loads of SMPT and NNTP, but in many loads the latency guarantees are a rather important part of it, and you'll have benchmarks that literally test how high ...
Sounds good. I want to inject some fresh ideas into this discussion from a completely different viewpoint, who knows I might get lucky and make things better. All you can do with the LSM is return -EPERM when the normal unix permissions would not have allowed an operation. I don't see where there is any magic or mystery in that, or any need for deep understanding. What we want from the LSM is the ability to say -EPERM when we can clearly articulate that we want to disallow something. SElinux is not all encompassing or it is generally incomprehensible I don't know which. Or someone long ago would have said a better way to implement containers was with a selinux ruleset, here is a selinux ruleset that does that. Although it is completely possible to implement all of the isolation with the existing LSM hooks as Serge showed. It is a legitimate criticism of the LSM that we are not improving our in-kernel abstractions to allow better concepts to base decisions upon when to return -EPERM. My first dealing with selinux and the lsm was when I fixed a security issue in /proc fixed the abstractions we were using and the default selinux security policy had a fit. If don't have good concepts in /proc/pid/xxx which is heavily used it would not surprise me at all if there are lots of other places in the kernel where our abstractions holes that have not yet been shorn up. We also have in the kernel another parallel security mechanism (for what is generally a different class of operations) that has been quite successful, and different groups get along quite well, and ordinary mortals can understand it. The linux firewalling code. The linux firewalling codes has hooks all throughout the networking stack, just like the LSM has hooks all throughout the rest of linux kernel. There is a difference however. The linux firewalling code in addition to hooks has tables behind those hooks that it consults. There is generic code to walk those tables and consult with ...
This sort of depends on perspective; typically with security infrastructure you actually want "... the ability to return success when we can clearly articulate that we want to *ALLOW* something". File permissions work this way; we don't have a list of forbidden users attached to each file, we have an owner, a group, and a mode representing positive permissions. With that said in certain high- risk environments you need something even stronger that cannot be The difference between SELinux and containers is that SELinux (and LSM as a whole) returns -EPERM to operations outside the scope of the subject, whereas containers return -ENOENT (because it's not even in Well, I wouldn't go so far as the "ordinary mortals can understand This is almost *EXACTLY* what SELinux provides as an LSM module. The one difference is that with SELinux some compromises and restrictions have been made so that (theoretically) the resulting policy can be exhaustively analyzed to *prove* what it allows and disallows. It may be that SELinux should be split into 2 parts, one that provides the underlying table-matching and the other that uses it to provide the provability guarantees. Here's a direct comparison: netfilter: (A) Each packet has src, dst, port, etc that can be matched (B) Table of rules applied sequentially (MATCH => ACTION) (C) Rules may alter the properties of packets as they are routed/ bridged/etc selinux: (A) Each object has user, role, and type that can be matched (B) Table of rules searched by object parameters (MATCH => allow/ auditallow/transition) (C) Rules may alter the properties of objects through transition rules. If there are areas where people are confused about SELinux, think it may be improved, etc, we would be *GLAD* to hear it. I'm currently struggling to find the time between a hundred other things to finish a script I offered to Casey Schaufler a month and a half ago which Actually the one ...
Yes. However last I looked at the LSM hooks we first do the normal unix permission checks. Then we run the hook. So it can only increase the Yes. However if you look at what the first implementations were. Especially something like linux-vserver. All they provided was isolation. So perhaps you would not see every process ps but they all had unique pid values. I'm pretty certain Serge at least prototyped a simplified version of that using the LSM hooks. Is there something I'm not remember in those hooks that allows hiding of information like processes? Yes. Currently with containers we are taking that one step farther as True. Probably a more accurate statement is:`unix command line power users can and do handle it after reading the docs. That's not quite ordinary mortals but it feels like it some days. It might all be Ok. There is something here. However in a generic setup, at least role would be an extended match criteria provided by the selinux module. It would not be a core attribute. It would need to depend on some extra functionality being How about thinking of it another way. Perform the split up you talked about above and move the table matching into the LSM hooks. Use something like the iptables action and match to module mapping code so we can have multiple modules compiled in and useable at the same time with the LSM hooks. I think it is firmly established that selling SElinux to everyone is politically untenable. However enhancing the LSM (even if it is mostly selinux code movement down a layer) I think can be sold. If I could run Serge's isolation code and selinux rules at the same time that would be interesting. My impression is that selinux is one monolithic blob that doesn't allow me to incrementally add matching or action features that I find interesting. Eric -
IMHO, containers have a subtly different purpose from LSM even though both are about information hiding. Basically a container is information hiding primarily for administrative reasons; either as a convenience to help prevent errors or as a way of describing administrative boundaries. For example, even in an environment where all sysadmins are trusted employees, a few head-honcho sysadmins would get root container access, and all others would get access to specific containers as a way of preventing "oops" errors. Basically a container is about "full access inside this box and no access outside". By contrast, LSM is more strictly about providing *limited* access to resources. For an accounting business all client records would grouped and associated together, however those which have passed this year's review are read-only except by specific staff and others may have information restricted to some subset of the employees. So containers are exclusive subsets of "the system" while LSM should I have seen more *wrong* iptables firewalls than I've seen correct ones. Securing TCP/IP traffic properly requires either a lot of training/experience or a good out-of-the-box system like Shorewall which structures the necessary restrictions for you based on an abstract description of the desired functionality. For instance what percentage of admins do you think could correctly set up their netfilter firewalls to log christmas-tree packets, smurfs, etc without the help of some external tool? Hell, I don't trust myself to reliably do it without a lot of reading of docs and testing, and I've been doing netfilter firewalls for a while. The bottom line is that with iptables it is *CRITICAL* to have a good set of interface tools to take the users' "My system is set up like..." description in some form and turn it into the necessary set of efficient security rules. The *exact* same issue applies to SELinux, with 2 major ...
Good suggestion. In fact, that is exactly how I approached my first two attempts at the problem. What you get if you take that route is an imposing infrastructure that has virually nothing to do and that adds no value to the solution. Programming to the LSM interface, on the other hand, allowed me to drastically reduce But Kyle, it's already possible to compile out the part I don't want. I configure SELinux off and away I go. Smack is not a subset of SELinux, it behaves differently. SELinux has a policy that is program behavior oriented, Smack is strictly subjet/object oriented. Your 4 components (A-D) are meaningless to The granularity and consequently the size of the policy specificiation result in policies that are too complicated. Tieing the policy to the expected behavior of specific applications adds to the complexity. SELinux is designed to increase in complexity as it evolves. Making Now what kind of tools are you talking about? Static analysis? That would be silly. Smack uses a significantly smaller set of hooks than SELinux requires and still does interesting things. We went through the "replace LSM with the SELinux interface" exercise a couple years Casey Schaufler casey@schaufler-ca.com -
It would be interesting to see the result of those first two attempts (even if they didn't get very far) just to see your approach and what To clarify, SELinux is also based on subjects and objects grouped into equivalence classes (labels), and the granularity at which one applies protection is configurable, so you can certainly have very coarse-grained labels that don't require any specific knowledge of application behavior. A type is just a security equivalence class - it doesn't have to map to an application at all. Also, the idea behind SELinux was that its policy engine (security server, security/selinux/ss/*) could be replaced with other implementations without affecting the rest of SELinux if someone wanted to try radically different logic. The interface to that policy engine Well, it reveals the complexity already present in the system, and gives you the option of controlling it. Your choice as to at what granularity I don't think Eric is proposing replacing LSM with the SELinux interface as it exists today, but rather making LSM more Netfilter-like and radically refactoring SELinux (and any other security module) to consist of a chain of smaller modules that are more general and reusable, and that can be composed and applied in interesting ways via an iptables-like interface. I'm not sure what that would look like exactly, but it seems reasonable to explore. One of the things left unresolved with LSM is userland API, and it does involve more than just returning EPERM or EACCES to applications. You already have patched ls and sshd programs, and have acknowledged the need for more userland modifications to ultimately achieve your own goals. If LSM is going to succeed in the kernel, then ultimately you need some common API for userland so that you don't need separate versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever. -- Stephen Smalley National Security Agency -
Woof. It weren't pretty, and I've carefully archived it so as The ss interface provides no advantage over the LSM interface that Which is the same for LSM. There are a bunch of LSM hooks that Smack does not need, and going into SELinux code to choose to do nothing The image that just flashed into my brain had a disturbing similarity to STREAMS modules, but spread everywhere, not just in the tty code. And anyone who thinks that there are too many LSM hooks now would have kittens over this. I don't think it's a bad idea, but I don't see how it would change the well documented disputes regarding what kinds of security behavior it ought to provide for. How would it help AppArmor, for example? I'm willing to bet (a beer or equivalence) that anything that helped there would face stiff resistance simply because it helped there. I could see it working if you restricted the interface to dealing with things that have security blobs, or even better to subjects and objects. But that's my security mindset, and I think pretty much yours, too. It's the policies that don't use good old Smack uses text strings for labels. It's amazing how many of the API issues evaporate when the only thing you have to do with your labels is compare them and print them. With the labels for processes available through /proc, and the labels for most things available via getxattr(2) and its variants the API issue seems hard to get worked up about. If ls(1) had an option to show selected extended attributes, and it really should by now, it wouldn't require fixing at all. Now sshd, login, and the rest of the authentification gaggle are going to need policy specific behavior so I feel no serious need to provide common API there. Smack is designed to make this easy because I had to do it the hard way before and didn't like it much. Casey Schaufler casey@schaufler-ca.com -
Yes. Simple isolation is a different and simpler problem that can be solved with the LSM hooks today. I brought it up for the contrast in what the LSM hooks can be useful for. Hopefully allowing the LSM hooks to be perceived as something other then just hacks for selinux. Using a security module for isolation is currently uninteresting because it would preclude use of a security module like selinux or smack, because we can have at most one security module at a time loaded. I have seen several other places where a custom LSM would have been a good solution but because we don't allow composition solving a little problem with the LSm is not interesting enough to allow the code to be merged. So I see the current structure of the LSM hooks as hindering Exactly refactoring security modules into small simple reusable chunks to allow reuse. It might look something like selinux chains or it might not. Inherently it needs to expose what you can do at the existing hook points, and it needs to allow usage by different modules that are compiled in at the same time. It is certainly the case that you would not need to use all of the Likely. Until we have a generalized LSM interface with 1000 config options like netfilter I don't expect we will have grounds to talk or agree to a common user space interface. Although I could be wrong. Eric -
Gulp. I know that many of you are granularity advocates, but I have to say that security derived by tweeking 1000 knobs so that they are all just right seems a little far fetched to me. I see it as poopooing the 3rd and most important part of the reference monitor concept, "small enough to analyze". Sure, you can analyse the 1000 individual checks, but you'll never be able to describe the system behavior as a whole. Casey Schaufler casey@schaufler-ca.com -
Agreed. I wasn't thinking 1000 individual checks but 1000 different capabilities, could be either checks or actions, basically fundamental different capabilities. Things like CIPSO, or the ability to store a security label on a file. I would not expect most security policies to use most of them. Neither do I expect Orange book security to necessarily be what people want to achieve with the LSM. But I haven't looked at it enough detail to know how things should be factored, in this case I was simply extrapolating from the iptables experience where we do have a very large number of options. The real point being is that I would be surprised if we could come to an agreement of a common user space API when we can't agree on how to compile all of the security modules into the kernel and have them play nice with each other. Assuming we can achieve security modules playing nice with each other using a mechanism similar to iptables, then what needs to be evaluated is the specific table configuration we are using on the system, not the full general set of possibilities. Further I expect that for the truly security paranoid we want the option to disable further table changes after the tables have been configured. On another side personally I don't see where the idea comes from that you can describe system behavior as a whole without analyzing the entire kernel. Has there been work on a sparse like tool that I'm not aware of to ensure the we always perform the appropriate security checks on the user/kernel interface boundary? Eric -
Yup, see the top of http://www.research.ibm.com/vali/ Pretty cool work that really should be continued. -serge -
You start getting into some pretty serious mindset battles on this particular road. For starters, the "hooks" have to be authoritative if you want them properly switchable, and I'm not going to show you the scars I got the last time I proposed authoritative hooks. Next you'll have to deal with defining what is security behavior and what isn't. You wouldn't believe the debates over the security implications, or lack thereof, of disk quotas. Unless you're willing to take the approach that every conditional in the kernel is a potential security checkpoint you are going to miss someone's requirement and if you're willing to propose that, The API issue cannot be solved if LSMs are going to implement different behaviors. A reasonable subset can be addressed using the POSIX P1003.1e/2c MAC definition plus the TSIG APIs. It is unfortunate that SELinux has gone in a completely different A specific table configuration sounds an awful lot like a specific SELinux Policy. Either way, your configuration is In addition to tools, there's the labor and money intensive Common Criteria Evaluation Process. Casey Schaufler casey@schaufler-ca.com -
(tongue-in-cheek) No no, everyone knows you don't build simpler things on top of more complicated ones, you go the other way around. So what he was -serge -
I'm not sure how seriously anyone ought to take what I'm about to
outline. Please feel free to treat it with as much or as little
reverence as you choose.
How to implement SELinux starting from Smack.
You'll need to break up the current rwxa accesses into a set
that matches the current SELinux set. Assign each a letter and
a "MAY_ACTION" #define.
You'll need a mapping for domain transitions, something like:
subject-label program-label new-subject-label
This will require bprm hooks that aren't there now.
Additional hooks will need to be filled out as Smack does not
add access control to things that aren't objects or actions that
aren't accesses. Treat these as if they are accesses to objects
and there shouldn't be too much trouble.
Do something about the linear search for subject/object label pairs.
With the larger label set searching will become an issue.
Audit integration, too. The networking code will require some work
for ipsec. The interfaces are pretty clean, Smack isn't using it
because the CIPSO interface is simpler, not because there's any
real problem with it.
I wouldn't expect the whole thing to be more than a couple week's
work for someone who really wanted to do it.
Casey Schaufler
casey@schaufler-ca.com
-
Note that Serge said "SELinux re-written on top of Smack", not "rewrite Smack to be more like SELinux". I don't believe the former is even possible, given that Smack is strictly less expressive and granular by design. Rewriting Smack to be more like SELinux should be possible, but seems like more work than emulating Smack on SELinux via policy, and to what end? -- Stephen Smalley National Security Agency -
Y'all keep saying that, but since noone has actually done that SELinux policy, or anything like it, I maintain that it's not as easy as you are inclined to claim. It is certainly not the "I'll Well, there is that. I personally think that one implementation of SELinux is plenty. On the other hand, I think that if the concept of a single security architecture has value the advocates of that position ought to be looking at SELinux on/of Smack just as carefully as they look at Smack on/of SELinux. If they are not, I suggest that the Single Security Architecture argument is a sophistic device rather than a legitimate issue of technology and should thus be ignored. Casey Schaufler casey@schaufler-ca.com -
Having gone from proposing a simpler and easier to use security system as an alternative to SELinux, you now propose to change the one working security system we have. And yes, it's hard to use, but it works. Let's keep this a patch, people who want adventure can have one, and people who have gotten Linux accepted "if SELinux is enabled" will avoid one. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -
But given that namespaces are making it upstream, what else is to be gained from the bsdail module? What exactly are you looking for? 1. are you looking to cover all the corner cases - i.e. prevent killing a process in another namespace through F_SETOWN or mqueue, etc? 2. are you looking for a potentially easier fix to the current absence of isolation in the user namespace? 3. are you just generally looking to make lsm/selinux easier for yourself to configure? If 1, an selinux policy should cover you. So you can then skip to 3. Or, alternatively, I do plan - as soon as my free time clears up a bit - on demonstrating how to write some selinux policy to create a secure container based on current -mm + your experimental network namespace patches. If 2, well, see 1. But for the long term solution, I don't think we want that in an LSM. Rather we want to implement proper user namespace enforcement in the kernel, then put 'policy' basically at the filesystem layer and further in userspace. So maybe not exactly what I've outlined before, but certainly similar. The filesystem can decide what user namespace a file belongs to, whether based on cryptographic keys stored with the file, or based on mount arguments, or something else. Users can get access to those files using keys stored with their task_struct if they are not in the right user namespace to otherwise access it. Otherwise access to a file in another user namespace defaults to the 3d mode bit, so you default to being 'other'. Further isolation probably still belongs in selinux or another lsm. If 3, then selinux policy modules may actually help you, else either a new LSM (maybe like LIDS) or a userspace tool which is a front-end to selinux policy, emulating the iptables rules formats, may be what you Actually with policy modules it gets much much better. I have in fact been able to pretty easily write a short policy module to, say, create an selinux user which ran as root and had full access to the ...
Good question. I keep tripping over the LSM hooks, and I have the distinct impression that part of the current contention and lack of agreement is simply the way things are current factored. So I'm putting for a constructive suggestion that has the possibility of I'm looking towards this yes. There are times when we deliberately allow mixing of things by the definition of what namespaces are and No. I'm not even worrying about the user namespace until it resembles complete. Currently I just view it as a stub because as is, the security namespace is pretty much useless for any case I think about. We still have way to many cases where the kernel treats different Well. I'm trying to make the LSM more useful to hack on and configure, and much less contentions for ordinary people to use. There is one issue with sockets that has come up where there are people who really want to filter things at connect and bind time. The LSM is so inflexible the only sane suggestion at the time was to duplicate the LSM hooks and add an new iptable style table for making that decision. Also I'm thinking towards what do we have to do isolate the security module stuff in the context of a namespace. So that a person in a container can setup their own rules that further restrict the system. So far I'm not ready to do anything yet but I'm keeping a weather eye I don't want to have to choose my LSM at compile time. I want to add support into the kernel at compile time and be able to configure it before I go multi-user. I know this kind of architecture is achievable because iptables allows it. When I conceive as the security modules as just a firewall between applications on my own box I think, oh yeah this is no big deal, I might want to limit something that way some time. These are just some additional rules on when to return -EPERM. So I ask myself why is this situation much less flexible and much harder to use then our Ok. Interesting. Are these kernel modules? Still ...
In the selinux example I plan to do set up soon, that will be done using the '.' namespace separator. Every object/subject in vserver1 will have a type 'vserver1.whatever'. 'vserver1.root_t', 'vserver1.etc_t', etc. I don't know how far the policy tools have gotten, but they are *supposed* to implement constraints at policy compile time such that every type which is a child of 'vserver1' would have no more access than what is granted to type 'vserver1'. So this provides a pretty nice conceptual way to set up security for a vserver. Then using the userspace policy server and metapolicy (this would be a step or two beyond my first example) the policy could define rules about what sort of policy could be added by a process of type 'vserver1.root_t'. So we can allow the container admin to introduce policy changes affecting only his own container, and subject to all It actually used to be far more flexible than it is now. The consensus appears to be that it's just too hard - at times impossible - to properly label every object or subject at some point after they've all been created (processes created, inodes read from disk, etc). Two examples: 1. you've got pid 777. How was it created? Can you trust it's history? In my DTE module I solved this by keeping track of the *full* invocation history until a policy was loaded. I think tomoyo may do something similar. But it's really not sufficient, especially since you don't even want a LSM loaded at all. So you can't reduce it to 'boot_t executd init_t executed login_t executed shell_t', you have to keep track of every inode executed 2. how do you reliably re-evaluate, for some file, what label to assign to it? Do you guess at a pathname? Do you trust that the inodes have been pre-labeled for every LSM, so when you load the LSM you can grab the xattrs? So it's a valid question - do we address these sorts of concerns in order to add flexibility, or do we keep things as simple as possible and say that ...
I want what we have for the rest of the kernel. The ability to build one kernel binary that can do everything and that is configured at boot time or run time. My perspective is that if we are going to have an in-kernel labeling operation running that may be an unconditional function that can only be enabled or disabled as the system runs. I'm not after the kind of flexibility that allows us to do things late in the game, at least not inherently. I'm after things like being able to have the checks separated from the labeling, roughly where are today with iptables. I'm really after refactoring the problem so that we don't get these winner take all fights for use of the LSM. If we can break things up into small enough factors so that a solution does not all come from one project then I think we have a chance of getting multiple security module authors to work together. Right now we don't seem to have that kind of cross pollination when using the LSM. But frankly even the ability to compile in all of the kernel security modules at compile time and be able to switch between them with a My perspective of the stacker module was that it's problem was it did not change the problem into a more useable form. That it didn't dig deep enough to have useful consequences. I don't think the goal was bad. In one sense what I'm proposing is putting the stacker functionality into the LSM. Allowing me to choose after I boot my kernel which of the compiled in security modules I want to run, and ideally for each logical kind of security test which order I call the security modules Communication error. I can't do small pieces that are useful in an upstreamable fashion. That is the problem I see. I don't care about out of kernel code. If we have to compile all of the code into the kernel and have no exports to modules that is fine with me. My question is how do we get more interesting functionality into the kernel. How do we get the generic kernel support simple and easy ...
To be very clear. Enhancing the LSM is of interest to me as it looks like that is a way to get people working and playing well together, and that ultimately to be able to run a full distro in a container I'm going to need this ability. Examples of better ways to do this in selinux, LIDS, or SMACK are only interesting as far as they suggest how to enhance the LSM. I honestly think enhancing the LSM would actually reduce it's ability to be abused, because nothing would directly own the hook. My very practical question: How do I run selinux in one container, and SMACK in another? Eric -
How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP in another? How would you run SMP in one and UP in the other? One aspect that SELinux and Smack share is that they only really provide security if all processes involved are under their control, just like the preemption behavior. This is not necessarily true of all possible LSMs. In that case it may be practicle to have different behavior for different containers. Casey Schaufler casey@schaufler-ca.com -
Well the style of kernel preemption is generally an implementation Right. But in a container that look like a full system arguably this is doable. There are a few additional details that would be needed to ensure containers are isolated from each other that would be When we get to the point where this is a real concern I believe the isolation will be sufficient that this it is a valid question to ask. If there is nothing visible to user space I don't care. But security modules are fundamentally about changing when -EPERM happens so are very visible to user space. Eric -
In the LSM model you don't because you could have the same container objects visible in different contains at the same time and subject to different LSMs. What does it mean to pass an SELinux protected object over an AppArmour protected unix domain socket into a SMACK protected container ? If you want consistency then you probably need to put the container id into the LSM calls and provide the ability in one system to do container specific checks. Right now I suspect the way to do it is to complete the work to convert SMACK rulesets into SELinux rulesets with tools. Really its the same problem as "I'd like to use different file permission systems on different process identifiers" and it would be very hard to get right simply because objects can pass between two different security models. Pyramid tried to do the "simple" case of BSD and System 5 on the same box and got caught out even with that because of the different rules on stuff like chgrp.. -
You raise a good point. My intuitive definition would go something like this. In the initial LSM space we would have whatever is the primary LSM and it would always be invoked about everything. However it would view a single container (no matter what user in that container) as having a single set of permissions. Then the LSM in the container be asked to further validate accesses, but it would distinguish between users in the container. At this point it looks like if I am going to be effective at doing anything I am going to need to step back watch SMACK get merged and then really look at what the LSM modules are implementing. Then I can refactor the whole mess and move additional functionality into Yep. Although the isolation of a container with a completely different set of namespaces is tight enough that except for people debugging a container from processes in the container from outside the container object exchange essentially doesn't happen. You do raise a very good question here. Does an LSM implement a different file permission system? Or does an LSM implement a firewall between processes? Certainly selinux seems too programmable to be considered just a Yes. There are many hard problems here and many people have tried and failed in the past. That hasn't stopped me before, and I don't see why security should be any different. Eric -
SELinux internally has a notion of a type hierarchy, where a type is limited to a subset of its parent's permissions, and one can then delegate the ability to manage sub-types via a policy daemon. But this is all handled in userspace; the kernel doesn't care about it. Ditto for the modular policy support - that's a userspace construct that is ultimately turned into a single coherent policy for the kernel to A LSM implements a security model, where that model may encompass all processes and objects. SELinux (and Smack) in particular implement mandatory access control and thus need to enforce consistent policy over all processes and objects based on their security labels. -- Stephen Smalley National Security Agency -
I think that you'll want to be careful with that approach. Smack and SELinux both implement mandatory access control, with very different mindsets too be sure, but MAC nonetheless. Smack doesn't use any LSM hooks that SELinux doesn't. You aren't going to get a very broad view of potential LSMs comparing these two. AppArmor and TOMOYO are much more likely to provide interesting alternative viewpoints. If you want to What he said as far as Smack and SELinux go. Other models need not encompass all processes and objects. Casey Schaufler casey@schaufler-ca.com -
Ok, finally getting some time to work on this stuff once again (life gets really crazy sometimes). I would like to postulate that you can restate any SMACK policy as a functionally equivalent SELinux policy (with a few slight technical differences, see below). I've been working on a script to do this but keep getting stuck tracking down minor bugs and then get dragged off on other things I need to do. Here is the method I am presently trying to implement: First divide the SELinux access vectors into 7 groups based on which ones SMACK wishes to influence: (R) Requires "read" permissions (the 'r' bit) (W) Requires "write" permissions (the 'w' bit) (X) Requires "execute" permissions (the 'x' bit) (A) Requires "append" OR "write" permissions (the 'a' bit) (P) Requires CAP_MAC_OVERRIDE (K) May not be performed by a non-CAP_MAC_OVERRIDE process on a CAP_MAC_OVERRIDE process (N) Does not require any special permissions The letters in front indicate the names I will use in the rest of this document to describe the sets of access vectors. Next define a single SELinux user "smack", and two independent roles, "priv" and "unpriv". We create the set of SMACK equivalence-classes defined as various SELinux types with substitutions for "*", "^", "_", and "?", and then completely omit the MLS portions of the SELinux policy. The next step is to establish the fundamental constraints of the policy. To prevent processes from gaining CAP_MAC_OVERRIDE we iterate over the access vectors in (K) and add the following constraint for each vector: constrain $OBJECT_CLASS $ACCESS_VECTOR ((r1 == r2) || (r1 == priv)) This also includes: constrain process transition ((r1 == r2) || (r1 == priv)) Then we require privilege to access the (P) vectors; for each vector in (P) we add a constraint: constrain $OBJECT_CLASS $ACCESS_VECTOR (r1 == priv) At this point the only rules left to add are the between-type rules. Here it gets mildly complicated ...
I'm still waiting to see the proposed SELinux policy that does what Smack does. I can accept that you don't see anything that can't be implemented thus, but that's not the point. You've provided some really clear design notes, and that's great, but it ain't the code. You said that you could write a 500 line perl script that would do the whole thing, and that left some people with an impression that Smack is a subset of SELinux. Well, I'm already finding myself digging out from under that missunderstanding, and with people who are assuming that your policy has been done, "proving" the point. I see nothing wrong with your approach, although I'm curious about how your emulation of capabilities will work, or if it's even rational to include in the SELinux context. I have my benchmark lab* ready to go when you have a policy for me to try. Thank you. ---- * It's a sony VAIO laptop with an 800MHZ AMD processor. Casey Schaufler casey@schaufler-ca.com -
That *is* the SELinux policy which does what Smack does. I keep having bugs in the perl-script I'm writing on account of not having the time to really get around to fixing it, but that is exactly the I'd love to have time to finish the script but unfortunately real life keeps interfering and I'm going to have to go back to lurking on this thread. Cheers, Kyle Moffett -
How about posting the partial one you've got ? -
In AppArmor, we plan to 'containerize' (not sure what to call it) policy so that you can have an AppArmor policy per container. This is not currently the case, it is just the direction we want to go. We think it would be very useful for virtual hosts to be able to have their own AppArmor policy, independent of what other hosts are doing. The major step towards this goal so far is that AppArmor rules are now canonicalized to the name space. However, I have never considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work -
Dear, Folks, Now we are planning to submit LIDS to mainline. (As you know, it already written for supporing LSM for several years.) When we will finish to re-write documentation and some FAQ, then we will be able to submit the patch. Sincerely, OMO -- Kazuki Omo: k-omo@sios.com Group Manager, OSS Technology Center Diary: http://omok.livejournal.com -
Most excellent. Thank you. Casey Schaufler casey@schaufler-ca.com -
I honestly think that the barrier has been more political in nature than technical. I don't know how long you've been watching, but no attempt to get an LSM upstream has escaped exagerated cricism from certain factions. Only someone who wants to get cut to metaphorical ribbons would submit a little LSM. Maybe that will get better now. I sure hope so. Casey Schaufler casey@schaufler-ca.com -
Yes. Me to. I certainly agree about the political part. My only hope was to suggest something that my reduce what there is to get political about. Eric -
Other than ACLs, of course, which do allow blacklisting individual users. -- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -
On Tue, 02 Oct 2007 17:02:13 -0400 To be fair the discussion on security does get down to real set theory but at that point most people's eyes (mine included) glaze over somewhat. You can reasonably quantify the behaviour and correctness of a security model based upon mathematical principles - if anything its *easier* that schedulers which are so much based on "feeling right". Smack seems a perfectly good simple LSM module, its clean, its based upon credible security models and sound theory (unlike AppArmor). I don't see why it shouldn't go in. Alan -
The problem with SELinux isn't the theory. It's the practice. IOW, it's too hard to use. Apparently Ubuntu is giving up on it too, for that reason. And what some people seem to have trouble admitting is that theory counts for nothing, if the practice isn't there. So quite frankly, the SELinux people would look at whole lot smarter if they didn't blather on about "theory". Linus -
I don't know if the field attracts the insane, or if being in the field drives one there, but I'm not going to deny that I'm pulling the whole arguement about when is pluggable good and when is it bad, as everybody seems inclined to use it to Sure, and I can emulate a rubber doorstop with Michealangeo's David, that doesn't make it a good idea. And I keep seeing "should", not Making SELinux bigger would not make it suit the typical Smack use Personally, I care about what I produced can do, and the uses to which it will be put. I am not convinced that SELinux can do many of the things that Smack can, and I know that a system that can only be used effectivly by Security Professionals is not for everyone. Smack has a different focus than SELinux. I see no need for hostility. If SELinux wants to incorporate Smack features, that's OK with me, but it won't make SELinux simpler. Heaven knows I have leaned heavily on the implementation example of SELinux. Casey Schaufler casey@schaufler-ca.com -
Something should be pluggable, and some things not. We have multiple filesystems in the tree; but we only have one scheduler and one TCP/IP stack. I'm going to argue that security is more like filesystems than scheduling. The real problem with security is that there are no "hard numbers", as Linus puts it. Instead, there are different sets of requirements in terms of what is a valid threat model --- which will very depending on the environment and how the servers are deployed, and what the capabilities are of the adversary trying to penetrate said system --- and how end users are willing to compromise between security and convenience. This is much like filesystems, where one of the reasons why people chose different filesystems is because they have differing requirements and operational environments, and some filesystems are better suited for certain requirements and environments than others. In some environments, say if you are creating a system that will handle classified data for the U.S. government, there are formal requirements that your employer, the NSA, sign off on the solution. This allows the NSA to force the application programmers and end users to make the tradeoff tilt very much against convenience in favor of security. And given the threat models and capabilities of the adversaries involved, that's probably appropriate. But that's not necessarily appropriate for all users. SELINUX is so horrible to use, that after wasting a large amount of time enabling it and then watching all of my applications die a horrible death since they didn't have the appropriate hand-crafted security policy, caused me to swear off of it. For me, given my threat model and how much my time is worth, life is too short for SELinux. And I can tell you that certain ISV's, when faced with users complaining that their commericial application which costs ten times as much as their Linux distribution doesn't work when SELinux is enabled, simply tells their customers to disable ...
Please recall the reason that we have LSM. It is so that Linus
Ah, the nut of the issue. What follows then is the argument that
SELinux should be the official security architecture of Linux.
Pulling LSM might slow a small set of abusers, but it wouldn't solve the
HeHe. I recall the response to some Tivoli developers when they
made a request not to long ago. I seriously doubt that they feel
Here our opinions diverge strongly. My position is that the
What is the #1 SELinux FAQ?
"How do I turn it off?"
I'd suggest that application and system developers are perfectly
capable of making rational decisions regarding the security model
The counter argument is of course VFS and the driver interface.
I think that the file systems work pretty well. Except for the
Why so defensive? SELinux is a fine implementation of Type Enforcement
and if you like that sort of thing I'm all for you using it. Accept that
it may not be for everyone. I certainly don't expect Smack on everyone's
machine.
Casey Schaufler
casey@schaufler-ca.com
-
I bet that the number of people submitting patches / possibly maintaining it is hyperbelic to the code size. Everyone that runs away from selinux's As long as one does not need to recompile userspace (like it is the case with libselinux), it wins. -
Ok, so to control smack label transitions, basically you would run with CAP_MAC_OVERRIDE (see my note later) so that you're allowed to change your smack label by writing to /proc/self/attr/current, then you drop CAP_MAC_OVERRIDE, then you're no longer able to change your label? I.e. no inherent label changing rules through smack itself? Just making sure I have that right. If I do, then I think at least defining the word 'privileged' above, given that this is mac, Might point out that no other modules must be compiled in along with Are you sure this isn't something you'd like to really audit? We're basically inevitably going to be switching to 64-bit caps "any day now". Should we just go ahead and do it here? Now maybe we should use a less contraversial name than 'mac override' like 'CAP_MAC_POLICY_ADMIN' :), but I guess CAP_MAC_OVERRIDE is honest. (I had started a 64-bit caps patch, but then got stuck trying to decide whether something needed to be done about task_capability_lock...) Well, I guess you wouldn't want to bog down your patch to that, but would you take your own bit once it was available, > + * as published by the Free Softwa
There is work required to audit, SELinux, and LSM that will be required before Smack or any other module can really use audit properly. Smack using audit would be nice, but there are already interesting cases that don't require it. I have fixing up audit on my todo list, and have made some proposals. It will require I would be delighted to have a bit of my very own. The granularity advocates might suggest I use more than one. Thank you for the comments. Casey Schaufler casey@schaufler-ca.com -
