Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Kazuki Omo(Company) [EMAIL PROTECTED] wrote: 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 Most excellent. Thank you. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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 Serge E. Hallyn wrote: (2007/10/09 03:00): Quoting Eric W. Biederman ([EMAIL PROTECTED]): 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. 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. 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. 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? 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? 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'. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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.
Cheers,
Kyle Moffett
-
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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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. How about posting the partial one you've got ? - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Quoting Eric W. Biederman ([EMAIL PROTECTED]): Kyle Moffett [EMAIL PROTECTED] writes: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: 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, 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. 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? Actually I had to introduce a new LSM hook to filter /proc pid listings. Yes. Currently with containers we are taking that one step farther as that solves a wider set of problems. And I'm far happier with the pid namespaces :) 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... 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. 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. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Serge E. Hallyn [EMAIL PROTECTED] writes: Quoting Eric W. Biederman ([EMAIL PROTECTED]): 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. But given that namespaces are making it upstream, what else is to be gained from the bsdail module? What exactly are you looking for? 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 going somewhere. 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? I'm looking towards this yes. There are times when we deliberately allow mixing of things by the definition of what namespaces are and there are some use cases where people don't want this. 2. are you looking for a potentially easier fix to the current absence of isolation in the user namespace? 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 names as the same name. 3. are you just generally looking to make lsm/selinux easier for yourself to configure? 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 on the situation so I have a clue what I'm go. 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. 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? 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Casey Schaufler ([EMAIL PROTECTED]): ... 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. :) 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 [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Quoting Eric W. Biederman ([EMAIL PROTECTED]): 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. 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. 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. 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? 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? 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'. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler [EMAIL PROTECTED] writes: --- Eric W. Biederman [EMAIL PROTECTED] wrote: 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Quoting Eric W. Biederman ([EMAIL PROTECTED]): Casey Schaufler [EMAIL PROTECTED] writes: --- Eric W. Biederman [EMAIL PROTECTED] wrote: 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. 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? Yup, see the top of http://www.research.ibm.com/vali/ Pretty cool work that really should be continued. -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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Serge E. Hallyn [EMAIL PROTECTED] writes: Quoting Eric W. Biederman ([EMAIL PROTECTED]): 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Eric W. Biederman [EMAIL PROTECTED] wrote: 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. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Eric W. Biederman [EMAIL PROTECTED] wrote: 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. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler [EMAIL PROTECTED] writes: --- Eric W. Biederman [EMAIL PROTECTED] wrote: 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Eric W. Biederman [EMAIL PROTECTED] wrote: Casey Schaufler [EMAIL PROTECTED] writes: --- Eric W. Biederman [EMAIL PROTECTED] wrote: 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. 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. 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, well, let's just say that Linus was right about security people. 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. 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 direction. 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. A specific table configuration sounds an awful lot like a specific SELinux Policy. Either way, your configuration is going to be large and may not implement anything rational. 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? In addition to tools, there's the labor and money intensive Common Criteria Evaluation Process. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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 ? 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.. - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Serge E. Hallyn wrote: (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. 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 [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Kyle Moffett wrote: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: 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, Other than ACLs, of course, which do allow blacklisting individual users. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote: Kyle Moffett [EMAIL PROTECTED] writes: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: 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. 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. Yes. Isolation is a much simpler problem than access control. 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... 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. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote: Kyle Moffett [EMAIL PROTECTED] writes: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: 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. 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. Yes. Isolation is a much simpler problem than access control. 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... 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. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Stephen Smalley [EMAIL PROTECTED] writes: On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote: Kyle Moffett [EMAIL PROTECTED] writes: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: 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. 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 development. 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. 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 existing hooks to get something done. 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. Eric - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 01:12:46AM +0100, Alan Cox wrote: 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Thu, Oct 04, 2007 at 07:18:47PM -0400, Chuck Ebbert wrote: 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote: Kyle Moffett [EMAIL PROTECTED] writes: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: 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. 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. 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... 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. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
* Christoph Hellwig [EMAIL PROTECTED] [2007-10-02 10:14]: On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote: 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. 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Tue, 2 Oct 2007, Bill Davidsen wrote: 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). 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. Linus - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Tue, 02 Oct 2007 17:02:13 -0400 Bill Davidsen [EMAIL PROTECTED] wrote: Linus Torvalds wrote: On Mon, 1 Oct 2007, Stephen Smalley wrote: You argued against pluggable schedulers, right? Why is security different? Schedulers can be objectively tested. There's this thing called performance, that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Wed, 3 Oct 2007, Alan Cox wrote: Smack seems a perfectly good simple LSM module, its clean, its based upon credible security models and sound theory (unlike AppArmor). 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Tue, 2 Oct 2007, Bill Davidsen wrote: 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 RD 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. Bill, that's a *tuning* issue, not a scheduler logic issue. You can do that today. The scheduler has always had (well, *almost* always: I think the really really original one didn't) had tuning knobs. It in no way excuses any pluggable scheduler, because IT DOES NOT CHANGE THE PROBLEM. [ Side note: not only doesn't it change the problem, but a good scheduler tunes itself rather naturally for most things. In particular, for things that really are CPU-limited, the scheduler should be able to notice that, and will not aim for latency to the same degree. In fact, what is really important is that the scheduler notice that some programs are latency-critical AT THE SAME TIME as other programs sharing that CPU are not, which very much implies that you absolutely MUST NOT have a scheduler that done one or the other: it needs to know about *both* behaviors at the same time. IOW, it is very much *not* about multiple different pluggable modules, because the scheduler must be able to work *across* these kinds of barriers. ] So for example, with the current scheduler, you can actually set things like scheduler latency. Exactly so you can tune things. However, I actually would argue that you generally shouldn't need to, and if you really do need to, and it's a huge deal for a real load (and not just a few percent for a benchmark), we should consider that a scheduler problem. So your argument is nonsense. You're arguing for something else than what you _claim_ to be arguing for. What you state that you want actually has nothing what-so-ever to do with pluggable schedulers, quite the reverse! It's also totally incorrect to state that this is somehow intrisicly a feature of a server load. Many server loads have very real latency constraints. No, not the traditional UNIX loads of SMPT and NNTP, but in many loads the latency guarantees are a rather important part of it, and you'll have benchmarks that literally test how high the load can be until latency reaches some intolerable value - ie latency ends up being the critical part. There's also a meta-development issue here: I can state with total conviction that historically, if we had had a server scheduler and a desktop scheduler, we'd have been in much worse shape than we are now. Not only are a lot of the loads the same or at least similar (and aiming for _one_ scheduler - especially one that auto-tunes itself at least to to some degree - gets you lots of good testing), but the hardware situation changes. For example, even just five years ago, there would have been people who thought that multiprocessing is a server load - and they'd have been largely right at the time. Would you have wanted a server (SMP, screw latency) scheduler, a workstation (SMP but low-latency) scheduler and a desktop (UP) scheduler for the different cases? Because yes, SMP does impact the scheduler a lot... The locking, the migration between CPU's, the CPU affinity.. Things that gamers five years ago would have felt was just totally screwing them over and making the scheduler slower and more complex for no gain. See? Pluggable things are generally a *bad* thing. You should generally aim for *never* being pluggable if you can at all avoid it, because it not only fragments the developer base over totally different code bases, it generates unmaintainable decisions as the problem space evolves. 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. 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. Quite frankly a lot of other people
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: 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. And you claim you are not a security expert :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sun, 30 Sep 2007, Andrew Morton wrote: So with the information which I presently have available to me, I'm thinking that this should go into 2.6.24. I think the decision to merge Smack is something that needs to be considered in the wider context of overall security architecture. Smack itself looks fine. It seems like clean code with interesting ideas, and appears to be based upon sound principles. Merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed. LSM's weak semantics and pervasive deep hooking of the kernel means that we'll have to continue dealing with several unpleasant issues, such as the abuse of the API by out of tree vendors, with a proliferation of binary/proprietary modules which typically maladapt the API for arbitrary purposes and/or use dangerous techniques. We will continue to waste resources maintaining this capability for them. On a broader scale, we'll miss the potential of Linux having a coherent, semantically strong security architecture. I have written about this in some detail before: http://lwn.net/Articles/240019/ Briefly, SELinux is a security architecture. It provides an extremely high degree of flexibility, in terms of both the types of security models implemented, and security policy for those models. It allows controlled composition of different security models, with a common policy language framework, allowing the entire system to be analyzed. The same ideas and even code can be reused beyond the kernel as post-DAC security is extended into databases, the desktop, distributed applications etc. It is a framework which provides a structured, coherent view of the security of the OS (and ultimately, the entire distributed environment). If LSM remains, security will never be a first class citizen of the kernel. Application developers will see multiple security schemes, and either burn themselves trying to support them, or more likely, ignore them. Core kernel developers will continue to not have enough information to understand what the LSM hooks in their code are supposed to be doing, leading to long term maintenance issues and potential security problems. LSM will remain a magnet for bad ideas. There's a reason we don't have pluggable network stacks, and we are lucky to have had a unified networking framework maintained by people who know to say no to things like STREAMS and TOE. I would question whether this quality of maintainership would exist if the networking core was simply a bunch of deep hooks into which people dumped arbitrary custom stacks. LSM will prevent us from making systemic improvements to security, as there will be no common security architecture. Things like Netfilter would not have been viable with a kernel which simply provided a bunch of hooks for networking stacks and an assortment of implementations. Much of this we have learned from the experience of LSM, and I think it has been valuable for that, but I think we need to consider now whether we are going to continue down this track in a permanent manner. - James -- James Morris [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, 1 Oct 2007, James Morris wrote: Merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed. Hell f*cking NO! You security people are insane. I'm tired of this only my version is correct crap. The whole and only point of LSM was to get away from that. And anybody who claims that there is consensus on SELinux is just in denial. People are arguing against other peoples security on totally bogus points. First it was AppArmor, now this. I guess I have to merge AppArmor and SMACK just to get this *disease* off the table. You're acting like a string theorist, claiming that t here is no other viable theory out there. Stop it. It's been going on for too damn long. Linus - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- James Morris [EMAIL PROTECTED] wrote: On Sun, 30 Sep 2007, Andrew Morton wrote: So with the information which I presently have available to me, I'm thinking that this should go into 2.6.24. I think the decision to merge Smack is something that needs to be considered in the wider context of overall security architecture. Please recall the reason that we have LSM. It is so that Linus does not have to listen to the arguments over security architecture. Smack itself looks fine. It seems like clean code with interesting ideas, and appears to be based upon sound principles. Thank you. Merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed. Ah, the nut of the issue. What follows then is the argument that SELinux should be the official security architecture of Linux. I disagree (like you hadn't figured that out) with this position. LSM's weak semantics and pervasive deep hooking of the kernel means that we'll have to continue dealing with several unpleasant issues, such as the abuse of the API by out of tree vendors, Pulling LSM might slow a small set of abusers, but it wouldn't solve the problem, what with well documented VFS and driver layers available. with a proliferation of binary/proprietary modules which typically maladapt the API for arbitrary purposes and/or use dangerous techniques. We will continue to waste resources maintaining this capability for them. HeHe. I recall the response to some Tivoli developers when they made a request not to long ago. I seriously doubt that they feel the community is putting out much for them. On a broader scale, we'll miss the potential of Linux having a coherent, semantically strong security architecture. I have written about this in some detail before: http://lwn.net/Articles/240019/ Here our opinions diverge strongly. My position is that the security architecture of SELinux is excessive in it's sophistication. Briefly, SELinux is a security architecture. It provides an extremely high degree of flexibility, in terms of both the types of security models implemented, and security policy for those models. It allows controlled composition of different security models, with a common policy language framework, allowing the entire system to be analyzed. The same ideas and even code can be reused beyond the kernel as post-DAC security is extended into databases, the desktop, distributed applications etc. It is a framework which provides a structured, coherent view of the security of the OS (and ultimately, the entire distributed environment). None of which is new or unique to SELinux. If LSM remains, security will never be a first class citizen of the kernel. Application developers will see multiple security schemes, and either burn themselves trying to support them, or more likely, ignore them. What is the #1 SELinux FAQ? How do I turn it off? I'd suggest that application and system developers are perfectly capable of making rational decisions regarding the security model that is appropriate to their environments. Core kernel developers will continue to not have enough information to understand what the LSM hooks in their code are supposed to be doing, leading to long term maintenance issues and potential security problems. Is that hypothetical, or do you have examples? LSM will remain a magnet for bad ideas. Thanks a lot. There's a reason we don't have pluggable network stacks, and we are lucky to have had a unified networking framework maintained by people who know to say no to things like STREAMS and TOE. I would question whether this quality of maintainership would exist if the networking core was simply a bunch of deep hooks into which people dumped arbitrary custom stacks. The counter argument is of course VFS and the driver interface. I think that the file systems work pretty well. Except for the flakey ones. LSM will prevent us from making systemic improvements to security, as there will be no common security architecture. Things like Netfilter would not have been viable with a kernel which simply provided a bunch of hooks for networking stacks and an assortment of implementations. Unless you consider Smack a systemic improvement to security like I do. Much of this we have learned from the experience of LSM, and I think it has been valuable for that, but I think we need to consider now whether we are going to continue down this track in a permanent manner. Why so defensive? SELinux is a fine implementation of Type Enforcement and if you like that sort of thing I'm all for you using it. Accept that it may not be for everyone. I certainly don't expect Smack on everyone's machine. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote: On Mon, 1 Oct 2007, James Morris wrote: Merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed. Hell f*cking NO! You security people are insane. I'm tired of this only my version is correct crap. The whole and only point of LSM was to get away from that. And anybody who claims that there is consensus on SELinux is just in denial. People are arguing against other peoples security on totally bogus points. First it was AppArmor, now this. I guess I have to merge AppArmor and SMACK just to get this *disease* off the table. You're acting like a string theorist, claiming that t here is no other viable theory out there. Stop it. It's been going on for too damn long. You argued against pluggable schedulers, right? Why is security different? Do you really want to encourage people to roll their own security module rather than working toward a common security architecture and a single balanced solution (which doesn't necessarily mean SELinux, mind you, but certainly could draw from parts of it)? As with pluggable schedulers, the LSM approach prevents cross pollination and forces users to make poor choices. Some have suggested that security modules are no different than filesystem implementations, but filesystem implementations at least are constrained by their need to present a common API and must conform with and leverage the VFS infrastructure. Different security modules present very different interfaces and behaviors from one another and LSM doesn't provide the same kind of common functionality and well-defined semantics as the VFS. The result of merging many wildly different security modules will be chaos for application developers and users, likely leading them to ignore everything but the least common denominator. It almost makes more sense to merge no security modules at all than to have LSM and many different security modules. If Smack is mergeable despite likely being nothing more than a strict subset of SELinux (MAC, label-based, should be easily emulated on top of SELinux or via fairly simple extension to it to make such emulation simpler or more optimal), then what isn't mergeable as a separate security module? -- Stephen Smalley National Security Agency - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, 1 Oct 2007, Stephen Smalley wrote: You argued against pluggable schedulers, right? Why is security different? Schedulers can be objectively tested. There's this thing called performance, that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is hard science. The other one is people wanking around with their opinions. If you guys had been able to argue on hard data and be in agreement, LSM wouldn't have been needed in the first place. BUT THAT WAS NOT THE CASE. And perhaps more importantly: BUT THAT IS *STILL* NOT THE CASE! Sorry for the shouting, but I'm serious about this. Do you really want to encourage people to roll their own security module rather than working toward a common security architecture and a single balanced solution (which doesn't necessarily mean SELinux, mind you, but certainly could draw from parts of it)? As with pluggable schedulers, the LSM approach prevents cross pollination and forces users to make poor choices. Another difference is that when it comes to schedulers, I feel like I actually can make an informed decision. Which means that I'm perfectly happy to just make that decision, and take the flak that I get for it. And I do (both decide, and get flak). That's my job. In contrast, when it comes to security, I see people making IDIOTIC arguments, and I absolutely *know* that those arguments are pure and utter crap, and at the same time, I see that those people are supposed to be experts. For example, you security guys still debate inodes vs pathnames, as if that was an either-or issue. Quite frankly, I'm not a security person, but I can tell a bad argument from a good one. And an argument that says inodes _or_ pathnames is so full of shit that it's not even funny. And a person who says that it has to be one or the other is incompetent. Yet that is *still* the level of disagreement I see. So LSM stays in. No ifs, buts, maybes or anything else. When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can hope. If Smack is mergeable despite likely being nothing more than a strict subset of SELinux (MAC, label-based, should be easily emulated on top of SELinux or via fairly simple extension to it to make such emulation simpler or more optimal), then what isn't mergeable as a separate security module? I'm simply not interested in this discussion. If you cannot understand the *meta*discussion above (which has nothing to do with SMACK or SELinux per se), I cannot help you. The biggest reason for me to merge SMACK (and AppArmor) would not be those particular security modules in themselves, but to inject a sense of reality in people. Right now, I see discussions about removign LSM because SELinux is everything. THAT IS A PROBLEM. Linus - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Stephen Smalley [EMAIL PROTECTED] wrote: On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote: On Mon, 1 Oct 2007, James Morris wrote: Merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed. Hell f*cking NO! You security people are insane. I don't know if the field attracts the insane, or if being in the field drives one there, but I'm not going to deny that we have our share of high grade loonies. I'm tired of this only my version is correct crap. The whole and only point of LSM was to get away from that. And anybody who claims that there is consensus on SELinux is just in denial. People are arguing against other peoples security on totally bogus points. First it was AppArmor, now this. I guess I have to merge AppArmor and SMACK just to get this *disease* off the table. You're acting like a string theorist, claiming that t here is no other viable theory out there. Stop it. It's been going on for too damn long. I'm pulling the whole arguement about when is pluggable good and when is it bad, as everybody seems inclined to use it to support thier own position. If Smack is mergeable despite likely being nothing more than a strict subset of SELinux Hogwash. (MAC, label-based, Yes. should be easily emulated on top of SELinux Sure, and I can emulate a rubber doorstop with Michealangeo's David, that doesn't make it a good idea. And I keep seeing should, not is. Emphatic assertion is not evidence. or via fairly simple extension to it to make such emulation simpler or more optimal), Making SELinux bigger would not make it suit the typical Smack use better. Smack is simplified, that's a major point. then what isn't mergeable as a separate security module? Personally, I care about what I produced can do, and the uses to which it will be put. I am not convinced that SELinux can do many of the things that Smack can, and I know that a system that can only be used effectivly by Security Professionals is not for everyone. Smack has a different focus than SELinux. I see no need for hostility. If SELinux wants to incorporate Smack features, that's OK with me, but it won't make SELinux simpler. Heaven knows I have leaned heavily on the implementation example of SELinux. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, Oct 01, 2007 at 09:04:44AM -0700, Linus Torvalds wrote: 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. Not so much incompetent as religious fundamentalist. Which is worse. OG. - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, Oct 01, 2007 at 11:40:39AM -0400, Stephen Smalley wrote: You argued against pluggable schedulers, right? Why is security different? Do you really want to encourage people to roll their own security module rather than working toward a common security architecture and a single balanced solution (which doesn't necessarily mean SELinux, mind you, but certainly could draw from parts of it)? As with pluggable schedulers, the LSM approach prevents cross pollination and forces users to make poor choices. Something should be pluggable, and some things not. We have multiple filesystems in the tree; but we only have one scheduler and one TCP/IP stack. I'm going to argue that security is more like filesystems than scheduling. The real problem with security is that there are no hard numbers, as Linus puts it. Instead, there are different sets of requirements in terms of what is a valid threat model --- which will very depending on the environment and how the servers are deployed, and what the capabilities are of the adversary trying to penetrate said system --- and how end users are willing to compromise between security and convenience. This is much like filesystems, where one of the reasons why people chose different filesystems is because they have differing requirements and operational environments, and some filesystems are better suited for certain requirements and environments than others. In some environments, say if you are creating a system that will handle classified data for the U.S. government, there are formal requirements that your employer, the NSA, sign off on the solution. This allows the NSA to force the application programmers and end users to make the tradeoff tilt very much against convenience in favor of security. And given the threat models and capabilities of the adversaries involved, that's probably appropriate. But that's not necessarily appropriate for all users. SELINUX is so horrible to use, that after wasting a large amount of time enabling it and then watching all of my applications die a horrible death since they didn't have the appropriate hand-crafted security policy, caused me to swear off of it. For me, given my threat model and how much my time is worth, life is too short for SELinux. And I can tell you that certain ISV's, when faced with users complaining that their commericial application which costs ten times as much as their Linux distribution doesn't work when SELinux is enabled, simply tells their customers to disable SELinux. I've often thought that one of the reasons why SELinux folks argue so strenuously against AppArmor is because since configuring it to support new applications is so much easier than SELinux, that on an even playing ground, in many commercial environments that dwarf the NSA-mandated security pain of the federal sector, there is fear that AppArmor would be much more popular with customers than SELinux. Yes, AppArmor protects against fewer threats; but if the choice is to go without SELinux because it's too painful to configure SELinux policy, surely some protection is better than none. Some have suggested that security modules are no different than filesystem implementations, but filesystem implementations at least are constrained by their need to present a common API and must conform with and leverage the VFS infrastructure. Different security modules present very different interfaces and behaviors from one another and LSM doesn't provide the same kind of common functionality and well-defined semantics as the VFS. The result of merging many wildly different security modules will be chaos for application developers and users, likely leading them to ignore everything but the least common denominator. It almost makes more sense to merge no security modules at all than to have LSM and many different security modules. Look, the reality is that the common interface for application is system calls returning EPERM. If you have to rewrite applications to use a security module, or force application writers to create a complicated SELinux policy, application writers will simply balk. It Just Won't Happen. Commercial applications like Oracle, DB2, Websphere, BEA Application Server, Tivoli Storage Manager, and so on work on multiple OS's, and not just Linux. If the application developers are forced to use a Linux-specific API, most of them will just walk away; it's much simpler and cheaper to tell users to disable SELinux. And in the commercial world, we don't have the big stick the NSA has in the federal/defense space to force application writers to pay attention to SELinux. The situation is just the same with filesystems. The common API is POSIX. As filesystem writers, we often kvetch about how limiting certain filesystem interfaces created 30 years ago might be, but the reality is, very few applications will use extended interfaces, and so if we broke readdir() and told application writers that they had to
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen [EMAIL PROTECTED] wrote: Anyways; if someone wants to cripple their security for some performance this way they can surely do this; but i don't think we should offer it as a default configuration option (just as we don't have a CONFIG_NULL_LSM even though there are undoubtedly systems that don't care about permission checking[1]) -Andi [1] I bet I gave the linux-tiny crowd an idea now ;-) You would need authoritative LSM hooks for this. The current LSM additional restrictions model does not provide for this. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sep 30 2007 01:16, Andrew Morton wrote: 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. 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 code size and/or complexity is a potential smack/aa user/contributor. 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? As long as one does not need to recompile userspace (like it is the case with libselinux), it wins. - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sat, 29 Sep 2007 17:20:36 -0700 Casey Schaufler [EMAIL PROTECTED] wrote: 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. 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. - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote: 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. 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. - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Andrew Morton [EMAIL PROTECTED] wrote: On Sat, 29 Sep 2007 17:20:36 -0700 Casey Schaufler [EMAIL PROTECTED] wrote: 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. 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. I've been leading with code, and working on the documentation less agressively. I will pick up the text pace. So with the information which I presently have available to me, I'm thinking that this should go into 2.6.24. That would be OK by me. Thank you. 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? Yes, haven't been pushing, don't know, and haven't a clue. What other userspace tools are likely to need patching? 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 policy compliation step involved. 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). Will do. - 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? Current feedback says they need more work. - 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 ruleset code was completly revised in Version 2. - 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?) Paul was the first person to whom I sent the patch. I would be delighted to have him review it again. - some parts of the code use the smack_foo naming convention and other parts use smk_foo. Seems odd. Deliberate? The original intent was an external vs internal distinction, but it greyed over time. I will look at cleaning this up. - 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. Thank you. The current set of interfaces and practices make kernel coding much easier than it was back in the Unix days. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen [EMAIL PROTECTED] wrote: - 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. - 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. - 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. 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. The authentication issues are very real, but a separate issue. 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. Casey Schaufler [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote: 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. 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. OK, this is news to me. What's the objection? 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 [EMAIL PROTECTED] - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
It does the job going off box, too. It does not as far as I can see. The IETF seems to have had very good reasons to never advance that draft any further. The authentication issues are very real, but a separate issue. 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 and you might as well not bother. 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. 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.). Adding a insecure additional placebo just doesn't seem like a good idea. I really doubt that you're suggesting that cryptographic authentication is required on the loopback interface. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
CIPSO is supported on SELinux as well. That's no reason to extend that design mistake. 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. If one of the boxes gets broken in all are compromised this way? 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Andi Kleen wrote: - 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. - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sun, Sep 30, 2007 at 07:39:57PM +0200, Andi Kleen wrote: 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. 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 CIPSO.) Security that isn't secure is not really useful. You might as well not bother. 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. Regards, - Ted - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Yes, normally the network is outside the Trusted Computing Base (TCB), Normally as in the 99.9% case. 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. 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 ;-) - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sunday 30 September 2007 3:07:42 pm Theodore Tso wrote: 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. Sorry I'm a bit late to the discussion (been busy doing weekend things), but I see that Casey, Josh, and Ted have already given a pretty good explanation of why CIPSO is not as evil as it appears at first glance. I won't restate the points they have already made, but I think there are two other points worth mentioning: The first is that CIPSO options are immutable, which means they work wonderfully with IPsec. Label integrity can be provided through the use of AH and/or tunneled ESP, label confidentiality can be provided through tunneled ESP. While the SELinux specific labeled IPsec implementation we currently have in the kernel is nice if you are talking to other SELinux machines, it has a very real handicap in that you can't use it to talk anything else. CIPSO, or CIPSO in combination with standard, non-labeled IPsec, can be used to talk to pretty much any trusted OSs out there. Adherence to standards and interoperability with other OSs have always been a key factor of Linux's acceptance into new areas; support for CIPSO is just another part of this drive for greater interoperability. The second point I wanted to make is that in the course of putting together the CIPSO implementation in the kernel I ended up talking with a few people who were involved in the original TSIG effort and the mess with the IETF. From what I could gather, the main technical complaint (other than a variety of political complaints which aren't relevant to our discussion here) was that CIPSO options are difficult to parse (they are, look at the format - it's an option within an option format - yuck) and the intermediate node vendors did not like it all (too much work to do in a fastpath ASIC). After all, look at the [R]IPSO RFC, dated only eight months earlier, and there is no cryptographic special sauce in that protocol. CIPSO isn't for everyone, I'll be the first to admit that. However, if you look at the mailing list archive for the Linux LSPP effort, the SELinux list, and to a lesser extent the netdev and LSM lists you will see that there are a set of users who care very much about this functionality. Our support of CIPSO is helping Linux operate in areas it wouldn't be able to elsewhere and I consider that a win. -- paul moore linux security @ hp - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sun, Sep 30, 2007 at 10:05:57PM +0200, Andi Kleen wrote: 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. 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 iSCSI, for example. 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? 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sunday 30 September 2007 4:16:18 am Andrew Morton wrote: - 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?) 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sun, 30 Sep 2007, Andi Kleen wrote: The authentication issues are very real, but a separate issue. First rule of network security: don't trust the network. This I agree with 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. 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 - 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Serge E. Hallyn [EMAIL PROTECTED] wrote:
...
+A process can see the smack label it is running with by
+reading /proc/self/attr/current. A privileged process can
+set the process smack by writing there.
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?
That is correct. Smack task labels do not change spontaniously.
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,
would help.
Good idea.
...
--- linux-2.6.23-rc8-base/security/smack/Kconfig1969-12-31
16:00:00.0 -0800
+++ linux-2.6.23-rc8-smack/security/smack/Kconfig 2007-09-25
15:30:38.0 -0700
@@ -0,0 +1,10 @@
+config SECURITY_SMACK
+ bool Simplified Mandatory Access Control Kernel Support
+ depends on NETLABEL SECURITY_NETWORK
+ default n
+ help
+ This selects the Simplified Mandatory Access Control Kernel.
+ Smack is useful for sensitivity, integrity, and a variety
+ of other mandatory security schemes.
+ If you are unsure how to answer this question, answer N.
Might point out that no other modules must be compiled in along with
smack, and that smack will do posix capabilities.
Also a good idea.
...
+/**
+ * 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;
+ if (strpbrk(modestr, wW) != NULL)
+ rule.smk_access |= MAY_WRITE;
+ if (strpbrk(modestr, xX) != NULL)
+ rule.smk_access |= MAY_EXEC;
+ if (strpbrk(modestr, aA) != NULL)
+ rule.smk_access |= MAY_APPEND;
+ smk_set_access(rule);
+ printk(%s:%d rule %s %s 0x%x\n, __func__, __LINE__,
+ (char *)rule.smk_subject, (char *)rule.smk_object,
+ rule.smk_access);
Are you sure this isn't something you'd like to really audit?
(Sorry if that's been asked before)
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
a group effort between audit, SELinux, Smack, and LSM.
...
+#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
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
