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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
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
> > 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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote: --- Kyle Moffett <[EMAIL PROTECTED]> wrote: [snipped] I'm still waiting to see the proposed SELinux policy that does what Smack does. That *is* the SELinux policy which does what Smack does. I keep having bugs in the perl-script I'm writing on account of not having the time to really get around to fixing it, but that is exactly the procedure for generating an SELinux policy from a SMACK policy. I can accept that you don't see anything that can't be implemented thus, but that's not the point. You've provided some really clear design notes, and that's great, but it ain't the code. You said that you could write a 500 line perl script that would do the whole thing, and that left some people with an impression that Smack is a subset of SELinux. Well, I'm already finding myself digging out from under that missunderstanding, and with people who are assuming that your policy has been done, "proving" the point. I'd love to have time to finish the script but unfortunately real life keeps interfering and I'm going to have to go back to lurking on this thread. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> 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.
I'm still waiting to see the proposed SELinux policy that does
what Smack does. I can accept that you don't see anything that
can't be implemented thus, but that's not the point. You've
provided some really clear design notes, and that's great, but
it ain't the code. You said that you could write a 500 line
perl script that would do the whole thing, and that left some
people with an impression that Smack is a subset of SELinux.
Well, I'm already finding myself digging out from under that
missunderstanding, and with people who are assuming that your
policy has been done, "proving" the point.
I see nothing wrong with your approach, although I'm curious
about how your emulation of capabilities will work, or if it's
even rational to include in the SELinux context. I have my
benchmark lab* ready to go when you have a policy for me to try.
Thank you.
* It's a sony VAIO laptop with an 800MHZ AMD processor.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote:
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.
I'm still waiting to see the proposed SELinux policy that does
what Smack does. I can accept that you don't see anything that
can't be implemented thus, but that's not the point. You've
provided some really clear design notes, and that's great, but
it ain't the code. You said that you could write a 500 line
perl script that would do the whole thing, and that left some
people with an impression that Smack is a subset of SELinux.
Well, I'm already finding myself digging out from under that
missunderstanding, and with people who are assuming that your
policy has been done, proving the point.
I see nothing wrong with your approach, although I'm curious
about how your emulation of capabilities will work, or if it's
even rational to include in the SELinux context. I have my
benchmark lab* ready to go when you have a policy for me to try.
Thank you.
* It's a sony VAIO laptop with an 800MHZ AMD processor.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: [snipped] I'm still waiting to see the proposed SELinux policy that does what Smack does. That *is* the SELinux policy which does what Smack does. I keep having bugs in the perl-script I'm writing on account of not having the time to really get around to fixing it, but that is exactly the procedure for generating an SELinux policy from a SMACK policy. I can accept that you don't see anything that can't be implemented thus, but that's not the point. You've provided some really clear design notes, and that's great, but it ain't the code. You said that you could write a 500 line perl script that would do the whole thing, and that left some people with an impression that Smack is a subset of SELinux. Well, I'm already finding myself digging out from under that missunderstanding, and with people who are assuming that your policy has been done, proving the point. I'd love to have time to finish the script but unfortunately real life keeps interfering and I'm going to have to go back to lurking on this thread. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Stephen Smalley <[EMAIL PROTECTED]> wrote: > On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote: > > Alan Cox <[EMAIL PROTECTED]> writes: > > > > >> My very practical question: How do I run selinux in one container, > > >> and SMACK in another? > > > > > > In the LSM model you don't because you could have the same container > > > objects visible in different contains at the same time and subject to > > > different LSMs. What does it mean to pass an SELinux protected object > > > over an AppArmour protected unix domain socket into a SMACK protected > > > container ? > > > > You raise a good point. My intuitive definition would go something like > > this. In the initial LSM space we would have whatever is the primary > > LSM and it would always be invoked about everything. However it > > would view a single container (no matter what user in that container) > > as having a single set of permissions. Then the LSM in the container > > be asked to further validate accesses, but it would distinguish > > between users in the container. > > SELinux internally has a notion of a type hierarchy, where a type is > limited to a subset of its parent's permissions, and one can then > delegate the ability to manage sub-types via a policy daemon. But this > is all handled in userspace; the kernel doesn't care about it. > > Ditto for the modular policy support - that's a userspace construct that > is ultimately turned into a single coherent policy for the kernel to > enforce. > > > At this point it looks like if I am going to be effective at doing > > anything I am going to need to step back watch SMACK get merged and > > then really look at what the LSM modules are implementing. Then > > I can refactor the whole mess and move additional functionality into > > the LSM to help me achieve other things. I think that you'll want to be careful with that approach. Smack and SELinux both implement mandatory access control, with very different mindsets too be sure, but MAC nonetheless. Smack doesn't use any LSM hooks that SELinux doesn't. You aren't going to get a very broad view of potential LSMs comparing these two. AppArmor and TOMOYO are much more likely to provide interesting alternative viewpoints. If you want to get carried away factor the audit code in, too. > > > Really its the same problem as "I'd like to use different file permission > > > systems on different process identifiers" and it would be very hard to > > > get right simply because objects can pass between two different security > > > models. > > > > Yep. Although the isolation of a container with a completely > > different set of namespaces is tight enough that except for people > > debugging a container from processes in the container from outside the > > container object exchange essentially doesn't happen. > > > > You do raise a very good question here. Does an LSM implement a > > different file permission system? Or does an LSM implement a firewall > > between processes? > > > > Certainly selinux seems too programmable to be considered just a > > different file permission system. > > A LSM implements a security model, where that model may encompass all > processes and objects. SELinux (and Smack) in particular implement > mandatory access control and thus need to enforce consistent policy over > all processes and objects based on their security labels. What he said as far as Smack and SELinux go. Other models need not encompass all processes and objects. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > > >> My very practical question: How do I run selinux in one container, > >> and SMACK in another? > > > > In the LSM model you don't because you could have the same container > > objects visible in different contains at the same time and subject to > > different LSMs. What does it mean to pass an SELinux protected object > > over an AppArmour protected unix domain socket into a SMACK protected > > container ? > > You raise a good point. My intuitive definition would go something like > this. In the initial LSM space we would have whatever is the primary > LSM and it would always be invoked about everything. However it > would view a single container (no matter what user in that container) > as having a single set of permissions. Then the LSM in the container > be asked to further validate accesses, but it would distinguish > between users in the container. SELinux internally has a notion of a type hierarchy, where a type is limited to a subset of its parent's permissions, and one can then delegate the ability to manage sub-types via a policy daemon. But this is all handled in userspace; the kernel doesn't care about it. Ditto for the modular policy support - that's a userspace construct that is ultimately turned into a single coherent policy for the kernel to enforce. > At this point it looks like if I am going to be effective at doing > anything I am going to need to step back watch SMACK get merged and > then really look at what the LSM modules are implementing. Then > I can refactor the whole mess and move additional functionality into > the LSM to help me achieve other things. > > > Really its the same problem as "I'd like to use different file permission > > systems on different process identifiers" and it would be very hard to > > get right simply because objects can pass between two different security > > models. > > Yep. Although the isolation of a container with a completely > different set of namespaces is tight enough that except for people > debugging a container from processes in the container from outside the > container object exchange essentially doesn't happen. > > You do raise a very good question here. Does an LSM implement a > different file permission system? Or does an LSM implement a firewall > between processes? > > Certainly selinux seems too programmable to be considered just a > different file permission system. A LSM implements a security model, where that model may encompass all processes and objects. SELinux (and Smack) in particular implement mandatory access control and thus need to enforce consistent policy over all processes and objects based on their security labels. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Alan Cox <[EMAIL PROTECTED]> writes: >> My very practical question: How do I run selinux in one container, >> and SMACK in another? > > In the LSM model you don't because you could have the same container > objects visible in different contains at the same time and subject to > different LSMs. What does it mean to pass an SELinux protected object > over an AppArmour protected unix domain socket into a SMACK protected > container ? You raise a good point. My intuitive definition would go something like this. In the initial LSM space we would have whatever is the primary LSM and it would always be invoked about everything. However it would view a single container (no matter what user in that container) as having a single set of permissions. Then the LSM in the container be asked to further validate accesses, but it would distinguish between users in the container. At this point it looks like if I am going to be effective at doing anything I am going to need to step back watch SMACK get merged and then really look at what the LSM modules are implementing. Then I can refactor the whole mess and move additional functionality into the LSM to help me achieve other things. > Really its the same problem as "I'd like to use different file permission > systems on different process identifiers" and it would be very hard to > get right simply because objects can pass between two different security > models. Yep. Although the isolation of a container with a completely different set of namespaces is tight enough that except for people debugging a container from processes in the container from outside the container object exchange essentially doesn't happen. You do raise a very good question here. Does an LSM implement a different file permission system? Or does an LSM implement a firewall between processes? Certainly selinux seems too programmable to be considered just a different file permission system. > 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.. Yes. There are many hard problems here and many people have tried and failed in the past. That hasn't stopped me before, and I don't see why security should be any different. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Alan Cox [EMAIL PROTECTED] writes: My very practical question: How do I run selinux in one container, and SMACK in another? In the LSM model you don't because you could have the same container objects visible in different contains at the same time and subject to different LSMs. What does it mean to pass an SELinux protected object over an AppArmour protected unix domain socket into a SMACK protected container ? You raise a good point. My intuitive definition would go something like this. In the initial LSM space we would have whatever is the primary LSM and it would always be invoked about everything. However it would view a single container (no matter what user in that container) as having a single set of permissions. Then the LSM in the container be asked to further validate accesses, but it would distinguish between users in the container. At this point it looks like if I am going to be effective at doing anything I am going to need to step back watch SMACK get merged and then really look at what the LSM modules are implementing. Then I can refactor the whole mess and move additional functionality into the LSM to help me achieve other things. Really its the same problem as I'd like to use different file permission systems on different process identifiers and it would be very hard to get right simply because objects can pass between two different security models. Yep. Although the isolation of a container with a completely different set of namespaces is tight enough that except for people debugging a container from processes in the container from outside the container object exchange essentially doesn't happen. You do raise a very good question here. Does an LSM implement a different file permission system? Or does an LSM implement a firewall between processes? Certainly selinux seems too programmable to be considered just a different file permission system. 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.. Yes. There are many hard problems here and many people have tried and failed in the past. That hasn't stopped me before, and I don't see why security should be any different. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote: Alan Cox [EMAIL PROTECTED] writes: My very practical question: How do I run selinux in one container, and SMACK in another? In the LSM model you don't because you could have the same container objects visible in different contains at the same time and subject to different LSMs. What does it mean to pass an SELinux protected object over an AppArmour protected unix domain socket into a SMACK protected container ? You raise a good point. My intuitive definition would go something like this. In the initial LSM space we would have whatever is the primary LSM and it would always be invoked about everything. However it would view a single container (no matter what user in that container) as having a single set of permissions. Then the LSM in the container be asked to further validate accesses, but it would distinguish between users in the container. SELinux internally has a notion of a type hierarchy, where a type is limited to a subset of its parent's permissions, and one can then delegate the ability to manage sub-types via a policy daemon. But this is all handled in userspace; the kernel doesn't care about it. Ditto for the modular policy support - that's a userspace construct that is ultimately turned into a single coherent policy for the kernel to enforce. At this point it looks like if I am going to be effective at doing anything I am going to need to step back watch SMACK get merged and then really look at what the LSM modules are implementing. Then I can refactor the whole mess and move additional functionality into the LSM to help me achieve other things. Really its the same problem as I'd like to use different file permission systems on different process identifiers and it would be very hard to get right simply because objects can pass between two different security models. Yep. Although the isolation of a container with a completely different set of namespaces is tight enough that except for people debugging a container from processes in the container from outside the container object exchange essentially doesn't happen. You do raise a very good question here. Does an LSM implement a different file permission system? Or does an LSM implement a firewall between processes? Certainly selinux seems too programmable to be considered just a different file permission system. A LSM implements a security model, where that model may encompass all processes and objects. SELinux (and Smack) in particular implement mandatory access control and thus need to enforce consistent policy over all processes and objects based on their security labels. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Stephen Smalley [EMAIL PROTECTED] wrote: On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote: Alan Cox [EMAIL PROTECTED] writes: My very practical question: How do I run selinux in one container, and SMACK in another? In the LSM model you don't because you could have the same container objects visible in different contains at the same time and subject to different LSMs. What does it mean to pass an SELinux protected object over an AppArmour protected unix domain socket into a SMACK protected container ? You raise a good point. My intuitive definition would go something like this. In the initial LSM space we would have whatever is the primary LSM and it would always be invoked about everything. However it would view a single container (no matter what user in that container) as having a single set of permissions. Then the LSM in the container be asked to further validate accesses, but it would distinguish between users in the container. SELinux internally has a notion of a type hierarchy, where a type is limited to a subset of its parent's permissions, and one can then delegate the ability to manage sub-types via a policy daemon. But this is all handled in userspace; the kernel doesn't care about it. Ditto for the modular policy support - that's a userspace construct that is ultimately turned into a single coherent policy for the kernel to enforce. At this point it looks like if I am going to be effective at doing anything I am going to need to step back watch SMACK get merged and then really look at what the LSM modules are implementing. Then I can refactor the whole mess and move additional functionality into the LSM to help me achieve other things. I think that you'll want to be careful with that approach. Smack and SELinux both implement mandatory access control, with very different mindsets too be sure, but MAC nonetheless. Smack doesn't use any LSM hooks that SELinux doesn't. You aren't going to get a very broad view of potential LSMs comparing these two. AppArmor and TOMOYO are much more likely to provide interesting alternative viewpoints. If you want to get carried away factor the audit code in, too. Really its the same problem as I'd like to use different file permission systems on different process identifiers and it would be very hard to get right simply because objects can pass between two different security models. Yep. Although the isolation of a container with a completely different set of namespaces is tight enough that except for people debugging a container from processes in the container from outside the container object exchange essentially doesn't happen. You do raise a very good question here. Does an LSM implement a different file permission system? Or does an LSM implement a firewall between processes? Certainly selinux seems too programmable to be considered just a different file permission system. A LSM implements a security model, where that model may encompass all processes and objects. SELinux (and Smack) in particular implement mandatory access control and thus need to enforce consistent policy over all processes and objects based on their security labels. What he said as far as Smack and SELinux go. Other models need not encompass all processes and objects. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Stephen Smalley <[EMAIL PROTECTED]> wrote: > On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote: > > ... > > I wouldn't expect the whole thing to be more than a couple week's > > work for someone who really wanted to do it. > > Note that Serge said "SELinux re-written on top of Smack", not "rewrite > Smack to be more like SELinux". Sorry, the subtlety of the difference seems insignificant to me. > I don't believe the former is even > possible, given that Smack is strictly less expressive and granular by > design. Rewriting Smack to be more like SELinux should be possible, As I outlined, it wouldn't be that hard to rewack SELinux from Smack. > but seems like more work than emulating Smack on SELinux via policy, Y'all keep saying that, but since noone has actually done that SELinux policy, or anything like it, I maintain that it's not as easy as you are inclined to claim. It is certainly not the "I'll whip it up this weekend" sort of task that some have suggested. > and to what end? Well, there is that. I personally think that one implementation of SELinux is plenty. On the other hand, I think that if the concept of a single security architecture has value the advocates of that position ought to be looking at SELinux on/of Smack just as carefully as they look at Smack on/of SELinux. If they are not, I suggest that the Single Security Architecture argument is a sophistic device rather than a legitimate issue of technology and should thus be ignored. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote: > --- "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. Note that Serge said "SELinux re-written on top of Smack", not "rewrite Smack to be more like SELinux". I don't believe the former is even possible, given that Smack is strictly less expressive and granular by design. Rewriting Smack to be more like SELinux should be possible, but seems like more work than emulating Smack on SELinux via policy, and to what end? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote: --- 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. Note that Serge said SELinux re-written on top of Smack, not rewrite Smack to be more like SELinux. I don't believe the former is even possible, given that Smack is strictly less expressive and granular by design. Rewriting Smack to be more like SELinux should be possible, but seems like more work than emulating Smack on SELinux via policy, and to what end? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Stephen Smalley [EMAIL PROTECTED] wrote: On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote: ... I wouldn't expect the whole thing to be more than a couple week's work for someone who really wanted to do it. Note that Serge said SELinux re-written on top of Smack, not rewrite Smack to be more like SELinux. Sorry, the subtlety of the difference seems insignificant to me. I don't believe the former is even possible, given that Smack is strictly less expressive and granular by design. Rewriting Smack to be more like SELinux should be possible, As I outlined, it wouldn't be that hard to rewack SELinux from Smack. but seems like more work than emulating Smack on SELinux via policy, Y'all keep saying that, but since noone has actually done that SELinux policy, or anything like it, I maintain that it's not as easy as you are inclined to claim. It is certainly not the I'll whip it up this weekend sort of task that some have suggested. and to what end? Well, there is that. I personally think that one implementation of SELinux is plenty. On the other hand, I think that if the concept of a single security architecture has value the advocates of that position ought to be looking at SELinux on/of Smack just as carefully as they look at Smack on/of SELinux. If they are not, I suggest that the Single Security Architecture argument is a sophistic device rather than a legitimate issue of technology and should thus be ignored. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Eric W. Biederman wrote: > My very practical question: How do I run selinux in one container, > and SMACK in another? > In AppArmor, we plan to 'containerize' (not sure what to call it) policy so that you can have an AppArmor policy per container. This is not currently the case, it is just the direction we want to go. We think it would be very useful for virtual hosts to be able to have their own AppArmor policy, independent of what other hosts are doing. The major step towards this goal so far is that AppArmor rules are now canonicalized to the name space. However, I have never considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: > > >> 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? Well the style of kernel preemption is generally an implementation detail that is not visible to user space. > How would you run SMP in one and UP in the other? Bind all of the UP processes to a single cpu. > 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. Right. But in a container that look like a full system arguably this is doable. There are a few additional details that would be needed to ensure containers are isolated from each other that would be needed to ensure this is effective but those are fairly minor. > This is not necessarily true of all possible LSMs. In that case it may > be practicle to have different behavior for different containers. When we get to the point where this is a real concern I believe the isolation will be sufficient that this it is a valid question to ask. If there is nothing visible to user space I don't care. But security modules are fundamentally about changing when -EPERM happens so are very visible to user space. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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]): > > > 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? I want what we have for the rest of the kernel. The ability to build one kernel binary that can do everything and that is configured at boot time or run time. My perspective is that if we are going to have an in-kernel labeling operation running that may be an unconditional function that can only be enabled or disabled as the system runs. I'm not after the kind of flexibility that allows us to do things late in the game, at least not inherently. I'm after things like being able to have the checks separated from the labeling, roughly where are today with iptables. I'm really after refactoring the problem so that we don't get these winner take all fights for use of the LSM. If we can break things up into small enough factors so that a solution does not all come from one project then I think we have a chance of getting multiple security module authors to work together. Right now we don't seem to have that kind of cross pollination when using the LSM. But frankly even the ability to compile in all of the kernel security modules at compile time and be able to switch between them with a kernel command line option would be a start. >> Still while I get the general impression that selinux seems to be >> very close to a generic solution, and that selinux more or less has >> the architecture we might want. I don't get the impression that >> selinux does this at a level that is open to other people doing >> interesting things. >> >> So I still ask the question can we move this functionality down to >> the LSM in a way that will solve the composition problem between >> multiple security modules? > > I've tried :) At a less semantic and more purely technical level, using > the stacker module. After a few years it was finally decided (at > ksummit 2006) that it simply wasn't useful. > > Now perhaps the problem was that I didn't address semantic issues. > But it does sound to me like what you want is a particular flexible LSM. > Be it LIDS or SELinux, or something new. My perspective of the stacker module was that it's problem was it did not change the problem into a more useable form. That it didn't dig deep enough to have useful consequences. I don't think the goal was bad. In one sense what I'm proposing is putting the stacker functionality into the LSM. Allowing me to choose after I boot my kernel which of the compiled in security modules I want to run, and ideally for each logical kind of security test which order I call the security modules in if I have more then one. >> 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. Communication error. I can't do small pieces that are useful in an upstreamable fashion. That is the problem I see. I don't care about out of kernel code. If we have to compile all of the code into the kernel and have no exports to modules that is fine with me. My question is how do we get more interesting functionality into the kernel. How do we get the generic kernel support simple and easy to hack so it can be used by people who have unique unanticipated problems. > 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. Quite likely, or at least I expect that they are close. I just think we should solve this at the LSM layer if it is at all possible not in selinux. > You also might want to check out LIDS, as its rules are set up pretty > much the way you seem to want. What is the kernel compile option for that? Or is LIDS yet another security module that hasn't made it upstream because the way the problem is currently factored it is nearly impossible to your code upstream? Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- "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. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Quoting Casey Schaufler ([EMAIL PROTECTED]): > > --- 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
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
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
Quoting Casey Schaufler ([EMAIL PROTECTED]): --- 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
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- 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. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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]): 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? I want what we have for the rest of the kernel. The ability to build one kernel binary that can do everything and that is configured at boot time or run time. My perspective is that if we are going to have an in-kernel labeling operation running that may be an unconditional function that can only be enabled or disabled as the system runs. I'm not after the kind of flexibility that allows us to do things late in the game, at least not inherently. I'm after things like being able to have the checks separated from the labeling, roughly where are today with iptables. I'm really after refactoring the problem so that we don't get these winner take all fights for use of the LSM. If we can break things up into small enough factors so that a solution does not all come from one project then I think we have a chance of getting multiple security module authors to work together. Right now we don't seem to have that kind of cross pollination when using the LSM. But frankly even the ability to compile in all of the kernel security modules at compile time and be able to switch between them with a kernel command line option would be a start. Still while I get the general impression that selinux seems to be very close to a generic solution, and that selinux more or less has the architecture we might want. I don't get the impression that selinux does this at a level that is open to other people doing interesting things. So I still ask the question can we move this functionality down to the LSM in a way that will solve the composition problem between multiple security modules? I've tried :) At a less semantic and more purely technical level, using the stacker module. After a few years it was finally decided (at ksummit 2006) that it simply wasn't useful. Now perhaps the problem was that I didn't address semantic issues. But it does sound to me like what you want is a particular flexible LSM. Be it LIDS or SELinux, or something new. My perspective of the stacker module was that it's problem was it did not change the problem into a more useable form. That it didn't dig deep enough to have useful consequences. I don't think the goal was bad. In one sense what I'm proposing is putting the stacker functionality into the LSM. Allowing me to choose after I boot my kernel which of the compiled in security modules I want to run, and ideally for each logical kind of security test which order I call the security modules in if I have more then one. 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. Communication error. I can't do small pieces that are useful in an upstreamable fashion. That is the problem I see. I don't care about out of kernel code. If we have to compile all of the code into the kernel and have no exports to modules that is fine with me. My question is how do we get more interesting functionality into the kernel. How do we get the generic kernel support simple and easy to hack so it can be used by people who have unique unanticipated problems. 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. Quite likely, or at least I expect that they are close. I just think we should solve this at the LSM layer if it is at all possible not in selinux. You also might want to check out LIDS, as its rules are set up pretty much the way you seem to want. What is the kernel compile option for that? Or is LIDS yet another security module that hasn't made it upstream because the way the problem is currently factored it is nearly impossible to your code upstream? Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 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? Well the style of kernel preemption is generally an implementation detail that is not visible to user space. How would you run SMP in one and UP in the other? Bind all of the UP processes to a single cpu. 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. Right. But in a container that look like a full system arguably this is doable. There are a few additional details that would be needed to ensure containers are isolated from each other that would be needed to ensure this is effective but those are fairly minor. This is not necessarily true of all possible LSMs. In that case it may be practicle to have different behavior for different containers. When we get to the point where this is a real concern I believe the isolation will be sufficient that this it is a valid question to ask. If there is nothing visible to user space I don't care. But security modules are fundamentally about changing when -EPERM happens so are very visible to user space. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Eric W. Biederman wrote: My very practical question: How do I run selinux in one container, and SMACK in another? In AppArmor, we plan to 'containerize' (not sure what to call it) policy so that you can have an AppArmor policy per container. This is not currently the case, it is just the direction we want to go. We think it would be very useful for virtual hosts to be able to have their own AppArmor policy, independent of what other hosts are doing. The major step towards this goal so far is that AppArmor rules are now canonicalized to the name space. However, I have never considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
--- Stephen Smalley <[EMAIL PROTECTED]> wrote: > ... > > > Good suggestion. In fact, that is exactly how I approached my > > first two attempts at the problem. What you get if you take that > > route is an imposing infrastructure that has virually nothing > > to do and that adds no value to the solution. Programming to the > > LSM interface, on the other hand, allowed me to drastically reduce > > the size and complexity of the implementation. > > It would be interesting to see the result of those first two attempts > (even if they didn't get very far) just to see your approach and what > obstacles you ran up against. Woof. It weren't pretty, and I've carefully archived it so as to make it hard to go back to for that very reason. Maybe someday. > ... > > Smack is not a subset of SELinux, it behaves differently. SELinux > > has a policy that is program behavior oriented, Smack is strictly > > subjet/object oriented. Your 4 components (A-D) are meaningless to > > Smack. > > To clarify, SELinux is also based on subjects and objects grouped into > equivalence classes (labels), and the granularity at which one applies > protection is configurable, so you can certainly have very > coarse-grained labels that don't require any specific knowledge of > application behavior. A type is just a security equivalence class - it > doesn't have to map to an application at all. > > Also, the idea behind SELinux was that its policy engine (security > server, security/selinux/ss/*) could be replaced with other > implementations without affecting the rest of SELinux if someone wanted > to try radically different logic. The interface to that policy engine > is itself general and not tied to TE. The ss interface provides no advantage over the LSM interface that I can see. > > > >>> I'm not yet annoyed enough to go implement an iptables like > > > >>> interface to the LSM enhancing it with more generic mechanism to > > > >>> make the problem simpler, but I'm getting there. Perhaps next > > > >>> time I'm bored. > > > >> > > > >> I think a fair amount of what we need is already done in SELinux, > > > >> and efforts would be better spent in figuring out what seems too > > > >> complicated in SELinux and making it simpler. > > > > The granularity and consequently the size of the policy specificiation > > result in policies that are too complicated. Tieing the policy to the > > expected behavior of specific applications adds to the complexity. > > Well, it reveals the complexity already present in the system, and gives > you the option of controlling it. Your choice as to at what granularity > to apply it. Which is the same for LSM. There are a bunch of LSM hooks that Smack does not need, and going into SELinux code to choose to do nothing is pretty pointless. > > SELinux is designed to increase in complexity as it evolves. Making > > it simpler would conflict with the design goal of finer granularity. > > > > > >> Probably a fair amount of that just means better tools. > > > > Now what kind of tools are you talking about? Static analysis? > > Data flow diagrammers for Java? > > > > > > How about thinking of it another way. > > > > > > > > Perform the split up you talked about above and move the table > > > > matching into the LSM hooks. > > > > > > > > Use something like the iptables action and match to module mapping > > > > code so we can have multiple modules compiled in and useable at the > > > > same time with the LSM hooks. > > > > > > > > I think it is firmly established that selling SElinux to everyone > > > > is politically untenable. However enhancing the LSM (even if it is > > > > mostly selinux code movement down a layer) I think can be sold. > > > > 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. The image that just flashed into my brain had a disturbing similarity to STREAMS modules, but spread everywhere, not just in the tty code. And anyone who thinks that there are too many LSM hooks now would have kittens over this. I don't think it's a bad idea, but I don't see how it would change the well documented disputes regarding what kinds of security behavior it ought to provide for. How would it help AppArmor, for example? I'm willing to bet (a beer or equivalence) that anything
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. > > > > > > >>>
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
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] wrote: ... Good suggestion. In fact, that is exactly how I approached my first two attempts at the problem. What you get if you take that route is an imposing infrastructure that has virually nothing to do and that adds no value to the solution. Programming to the LSM interface, on the other hand, allowed me to drastically reduce the size and complexity of the implementation. It would be interesting to see the result of those first two attempts (even if they didn't get very far) just to see your approach and what obstacles you ran up against. Woof. It weren't pretty, and I've carefully archived it so as to make it hard to go back to for that very reason. Maybe someday. ... Smack is not a subset of SELinux, it behaves differently. SELinux has a policy that is program behavior oriented, Smack is strictly subjet/object oriented. Your 4 components (A-D) are meaningless to Smack. To clarify, SELinux is also based on subjects and objects grouped into equivalence classes (labels), and the granularity at which one applies protection is configurable, so you can certainly have very coarse-grained labels that don't require any specific knowledge of application behavior. A type is just a security equivalence class - it doesn't have to map to an application at all. Also, the idea behind SELinux was that its policy engine (security server, security/selinux/ss/*) could be replaced with other implementations without affecting the rest of SELinux if someone wanted to try radically different logic. The interface to that policy engine is itself general and not tied to TE. The ss interface provides no advantage over the LSM interface that I can see. I'm not yet annoyed enough to go implement an iptables like interface to the LSM enhancing it with more generic mechanism to make the problem simpler, but I'm getting there. Perhaps next time I'm bored. I think a fair amount of what we need is already done in SELinux, and efforts would be better spent in figuring out what seems too complicated in SELinux and making it simpler. The granularity and consequently the size of the policy specificiation result in policies that are too complicated. Tieing the policy to the expected behavior of specific applications adds to the complexity. Well, it reveals the complexity already present in the system, and gives you the option of controlling it. Your choice as to at what granularity to apply it. Which is the same for LSM. There are a bunch of LSM hooks that Smack does not need, and going into SELinux code to choose to do nothing is pretty pointless. SELinux is designed to increase in complexity as it evolves. Making it simpler would conflict with the design goal of finer granularity. Probably a fair amount of that just means better tools. Now what kind of tools are you talking about? Static analysis? Data flow diagrammers for Java? How about thinking of it another way. Perform the split up you talked about above and move the table matching into the LSM hooks. Use something like the iptables action and match to module mapping code so we can have multiple modules compiled in and useable at the same time with the LSM hooks. I think it is firmly established that selling SElinux to everyone is politically untenable. However enhancing the LSM (even if it is mostly selinux code movement down a layer) I think can be sold. 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. The image that just flashed into my brain had a disturbing similarity to STREAMS modules, but spread everywhere, not just in the tty code. And anyone who thinks that there are too many LSM hooks now would have kittens over this. I don't think it's a bad idea, but I don't see how it would change the well documented disputes regarding what kinds of security behavior it ought to provide for. How would it help AppArmor, for example? I'm willing to bet (a beer or equivalence) that anything that helped there would face stiff resistance simply because it helped there. I could see it working if you restricted the interface to dealing with things that have security blobs, or
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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? Yes. Currently with containers we are taking that one step farther as that solves a wider set of problems. >> 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 figuring out what seems too complicated in SELinux > and > making it simpler. Probably a fair amount of that just means better tools. How about thinking of it another way. Perform the split up you
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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, 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). 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. 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. If there are areas where people are confused about SELinux, think it may be improved, etc, we would be *GLAD* to hear it. I'm currently struggling to find the time between a hundred other things to finish a script I offered to Casey Schaufler a month and a half ago which generated an SELinux policy based on a SMACK ruleset. So I propose that if people want to work towards a one true linux solution for additional security checks, then they should look towards the linux firewalling code. It works and it seems to very nicely allow cooperations between different groups. For the people who will scream mixing security models causes problems, the answer is simple recommend users don't set up their policies that way. Actually the one thing which really frustrates me about the Linux firewalling code is that you cannot selectively apply various transformation phases, they are automatically applied for you. I have had a couple very-transparent-routing-firewalling-bridging scenarios where I wished I could run the bridging phase, compare-and- change the result, and then run the bridging phase again to forward the packet elsewhere. For example if I was to set up a diverted ethernet port I would need to apply the bridging code, compare the destination port against the selected diverted port and change the MAC address, then reapply the bridging code. To mirror you would also need a phase which could create multiple clones of packets and conditionalize rules based on which of the copies it was. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds <[EMAIL PROTECTED]> writes: > To get back to security: I didn't want pluggable security because I > thought that was a technically good solution. No, the reason Linux has LSM > (and yes, I was the one who pushed hard for the whole thing, even if I > didn't actually write any of it) was because the problem wasn't technical > to begin with. > > It was social/political and administrative. > > See? Another fundamental difference between schedulers and security > modules. > > But no, that's not really why we have LSM. I'd have *much* preferred to > have one unified security module setup that we could all agree on, and no > pluggable security modules. It was not to be - and the reason we have LSM > is not because "it makes more sense than a CPU scheduler", but simply > because "people didn't actually get anything done at all, because they > just argued about what to do". > > In the CPU schedulers, Ingo still gets work done, even though people argue > about it. So we haven't needed to go to the extreme of an "LSM for CPU > schedulers", because the arguments don't actually hold up the work. > > And THAT is what matters in the end. Sounds good. I want to inject some fresh ideas into this discussion from a completely different viewpoint, who knows I might get lucky and make things better. All you can do with the LSM is return -EPERM when the normal unix permissions would not have allowed an operation. I don't see where there is any magic or mystery in that, or any need for deep understanding. What we want from the LSM is the ability to say -EPERM when we can clearly articulate that we want to disallow something. SElinux is not all encompassing or it is generally incomprehensible I don't know which. Or someone long ago would have said a better way to implement containers was with a selinux ruleset, here is a selinux ruleset that does that. Although it is completely possible to implement all of the isolation with the existing LSM hooks as Serge showed. It is a legitimate criticism of the LSM that we are not improving our in-kernel abstractions to allow better concepts to base decisions upon when to return -EPERM. My first dealing with selinux and the lsm was when I fixed a security issue in /proc fixed the abstractions we were using and the default selinux security policy had a fit. If don't have good concepts in /proc/pid/xxx which is heavily used it would not surprise me at all if there are lots of other places in the kernel where our abstractions holes that have not yet been shorn up. We also have in the kernel another parallel security mechanism (for what is generally a different class of operations) that has been quite successful, and different groups get along quite well, and ordinary mortals can understand it. The linux firewalling code. The linux firewalling codes has hooks all throughout the networking stack, just like the LSM has hooks all throughout the rest of linux kernel. There is a difference however. The linux firewalling code in addition to hooks has tables behind those hooks that it consults. There is generic code to walk those tables and consult with different 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. Meanwhile composition of a policy using code from different clients of the LSM hooks is impossible, and thus cooperation or wider use of the LSM hooks is difficult. So I propose that if people want to work towards a one true linux solution for additional security checks, then they should look towards the linux firewalling code. It works and it seems to very nicely allow cooperations between different groups. For the people who will scream mixing security models causes problems, the answer is simple recommend users don't set up their policies that way. I know we can't solve human problems with technical measures but perhaps a technical suggestion can open the way to the solution to some human problems. 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. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On 10/04/2007 06:56 PM, Derek Fawcus 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On 10/04/2007 06:56 PM, Derek Fawcus 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds [EMAIL PROTECTED] writes: To get back to security: I didn't want pluggable security because I thought that was a technically good solution. No, the reason Linux has LSM (and yes, I was the one who pushed hard for the whole thing, even if I didn't actually write any of it) was because the problem wasn't technical to begin with. It was social/political and administrative. See? Another fundamental difference between schedulers and security modules. But no, that's not really why we have LSM. I'd have *much* preferred to have one unified security module setup that we could all agree on, and no pluggable security modules. It was not to be - and the reason we have LSM is not because it makes more sense than a CPU scheduler, but simply because people didn't actually get anything done at all, because they just argued about what to do. In the CPU schedulers, Ingo still gets work done, even though people argue about it. So we haven't needed to go to the extreme of an LSM for CPU schedulers, because the arguments don't actually hold up the work. And THAT is what matters in the end. Sounds good. I want to inject some fresh ideas into this discussion from a completely different viewpoint, who knows I might get lucky and make things better. All you can do with the LSM is return -EPERM when the normal unix permissions would not have allowed an operation. I don't see where there is any magic or mystery in that, or any need for deep understanding. What we want from the LSM is the ability to say -EPERM when we can clearly articulate that we want to disallow something. SElinux is not all encompassing or it is generally incomprehensible I don't know which. Or someone long ago would have said a better way to implement containers was with a selinux ruleset, here is a selinux ruleset that does that. Although it is completely possible to implement all of the isolation with the existing LSM hooks as Serge showed. It is a legitimate criticism of the LSM that we are not improving our in-kernel abstractions to allow better concepts to base decisions upon when to return -EPERM. My first dealing with selinux and the lsm was when I fixed a security issue in /proc fixed the abstractions we were using and the default selinux security policy had a fit. If don't have good concepts in /proc/pid/xxx which is heavily used it would not surprise me at all if there are lots of other places in the kernel where our abstractions holes that have not yet been shorn up. We also have in the kernel another parallel security mechanism (for what is generally a different class of operations) that has been quite successful, and different groups get along quite well, and ordinary mortals can understand it. The linux firewalling code. The linux firewalling codes has hooks all throughout the networking stack, just like the LSM has hooks all throughout the rest of linux kernel. There is a difference however. The linux firewalling code in addition to hooks has tables behind those hooks that it consults. There is generic code to walk those tables and consult with different 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. Meanwhile composition of a policy using code from different clients of the LSM hooks is impossible, and thus cooperation or wider use of the LSM hooks is difficult. So I propose that if people want to work towards a one true linux solution for additional security checks, then they should look towards the linux firewalling code. It works and it seems to very nicely allow cooperations between different groups. For the people who will scream mixing security models causes problems, the answer is simple recommend users don't set up their policies that way. I know we can't solve human problems with technical measures but perhaps a technical suggestion can open the way to the solution to some human problems. 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. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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, 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). 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. 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. If there are areas where people are confused about SELinux, think it may be improved, etc, we would be *GLAD* to hear it. I'm currently struggling to find the time between a hundred other things to finish a script I offered to Casey Schaufler a month and a half ago which generated an SELinux policy based on a SMACK ruleset. So I propose that if people want to work towards a one true linux solution for additional security checks, then they should look towards the linux firewalling code. It works and it seems to very nicely allow cooperations between different groups. For the people who will scream mixing security models causes problems, the answer is simple recommend users don't set up their policies that way. Actually the one thing which really frustrates me about the Linux firewalling code is that you cannot selectively apply various transformation phases, they are automatically applied for you. I have had a couple very-transparent-routing-firewalling-bridging scenarios where I wished I could run the bridging phase, compare-and- change the result, and then run the bridging phase again to forward the packet elsewhere. For example if I was to set up a diverted ethernet port I would need to apply the bridging code, compare the destination port against the selected diverted port and change the MAC address, then reapply the bridging code. To mirror you would also need a phase which could create multiple clones of packets and conditionalize rules based on which of the copies it was. 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
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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? Yes. Currently with containers we are taking that one step farther as that solves a wider set of problems. 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 figuring out what seems too complicated in SELinux and making it simpler. Probably a fair amount of that just means better tools. How about thinking of it another way. Perform the split up you talked about above and move the table matching into the LSM hooks. Use something like the iptables
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
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 R 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.
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: 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). Actually I had quoted that, made a reply, and decided that my reply was too close to a flame and deleted the quote and the nasty reply, because I couldn't find a nice way to say what I wanted. Oh well, I tried to keep to a higher level, but... on this topic you seem to be off on an ego trip. You are not the decider, George Bush is the decider, and the only time he's not wrong he didn't understand the question. I checked the schedule, it's not you week to be God. There are sensible people you respect on other topics, who have the opinion that there is room for behaviors other than CFS, and who have created a pluggable scheduler framework which they are trying to hand you on a platter. And you won't even consider that they might be right, because you believe there can be one scheduler which is close to optimal for all loads. 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. Unfortunately not so, I've been looking at schedulers since MULTICS, and desktops since the 70s (MP/M), and networked servers since I was the ARPAnet technical administrator at GE's Corporate R 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. 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. Why do people believe that desktop doesn't have multiple processors or through-put intensive loads? Why are people continuing this *idiotic* scheduler discussion? Because people can't get you to understand that one size doesn't fit all (and I doubt I've broken through). 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 real issue is that you can't imagine that people who don't share your opinion are not only wrong but don't understand the problem. You may be right, but when you say anyone who disagrees is wrong by definition, then you have lost sight of productive technical differences. When your arguments drop to personal attacks and rants it's time to look at your technical values. 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. Exactly, and I'm not the only one who doubts that more than one model would be useful. I'm sorry you can't see that about CPU schedulers as well. 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. I don't
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
> situations. For example, I find SELinux to be so irrelevant to my usage
> that I don't use it at all. I just don't have any other users on my
> machine
That you know about...
The value of SELinux (or indeed any system compartmentalising access and
limiting damage) comes into play when you get breakage - eg via a web
browser exploit.
Yes SELinux is much more relevant to servers, and really comes into its
own when its used to write custom rulesets and enforce corporate policy
("No you can't run that screensaver that arrived by email").
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Tue, 2 Oct 2007, Linus Torvalds wrote: > > 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? Btw, one thing that is true: while both servers and desktop cares about latency, it's often easier to *see* the issues on the desktop (or hear them: audio skipping). But that doesn't mean that the server people wouldn't care, and it doesn't mean that scheduling would be "fundamentally different" on servers or the desktop. In contrast, security really *is* fundamentally different in different situations. For example, I find SELinux to be so irrelevant to my usage that I don't use it at all. I just don't have any other users on my machine, so the security I care about is in firewalls etc. And that really *is* fundamentally different from a system that has shell access to its users. Which in turn is fundamentally different from one that has some legal reasons why it needs to have a particular kind of security. Which in turn is fundamentally different from You get the idea. It boils down to: "scheduling is scheduling", and doesn't really change apart from the kind of decisions that are required by any scheduler (ie RT vs non-RT etc). Everybody wants the same thing in the end: low latency for loads where that matters, high bandwidth for loads where that matters. It's not a "one user has only one kind of load". Not at all. Security, on the other hand, very much does depend on the circumstances and the wishes of the users (or policy-makers). And if we had one module that everybody would be happy with, I'd not make it pluggable either. But as it is, we _know_ that's not the case. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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. You say "performance" as if it had universal meaning. In truth people want to optimize for total tps (servers), or responsiveness on the human scale (mail, dns, nntp servers), or perceived smoothness (with many threads updating a display to slow with load rather than start visibly jumping the motion from one to another), or very short term response (-rt patches). People want very different behavior under the same load, and that is what *they* call "performance," namely best delivery of what's important. The numbers are "hard science" but the choice of which numbers are important is still "people wanking around with their opinions". -- Bill Davidsen <[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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
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. You say performance as if it had universal meaning. In truth people want to optimize for total tps (servers), or responsiveness on the human scale (mail, dns, nntp servers), or perceived smoothness (with many threads updating a display to slow with load rather than start visibly jumping the motion from one to another), or very short term response (-rt patches). People want very different behavior under the same load, and that is what *they* call performance, namely best delivery of what's important. The numbers are hard science but the choice of which numbers are important is still people wanking around with their opinions. -- Bill Davidsen [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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Tue, 2 Oct 2007, Linus Torvalds wrote: 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? Btw, one thing that is true: while both servers and desktop cares about latency, it's often easier to *see* the issues on the desktop (or hear them: audio skipping). But that doesn't mean that the server people wouldn't care, and it doesn't mean that scheduling would be fundamentally different on servers or the desktop. In contrast, security really *is* fundamentally different in different situations. For example, I find SELinux to be so irrelevant to my usage that I don't use it at all. I just don't have any other users on my machine, so the security I care about is in firewalls etc. And that really *is* fundamentally different from a system that has shell access to its users. Which in turn is fundamentally different from one that has some legal reasons why it needs to have a particular kind of security. Which in turn is fundamentally different from You get the idea. It boils down to: scheduling is scheduling, and doesn't really change apart from the kind of decisions that are required by any scheduler (ie RT vs non-RT etc). Everybody wants the same thing in the end: low latency for loads where that matters, high bandwidth for loads where that matters. It's not a one user has only one kind of load. Not at all. Security, on the other hand, very much does depend on the circumstances and the wishes of the users (or policy-makers). And if we had one module that everybody would be happy with, I'd not make it pluggable either. But as it is, we _know_ that's not the case. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
situations. For example, I find SELinux to be so irrelevant to my usage that I don't use it at all. I just don't have any other users on my machine That you know about... The value of SELinux (or indeed any system compartmentalising access and limiting damage) comes into play when you get breakage - eg via a web browser exploit. Yes SELinux is much more relevant to servers, and really comes into its own when its used to write custom rulesets and enforce corporate policy (No you can't run that screensaver that arrived by email). Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: 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). Actually I had quoted that, made a reply, and decided that my reply was too close to a flame and deleted the quote and the nasty reply, because I couldn't find a nice way to say what I wanted. Oh well, I tried to keep to a higher level, but... on this topic you seem to be off on an ego trip. You are not the decider, George Bush is the decider, and the only time he's not wrong he didn't understand the question. I checked the schedule, it's not you week to be God. There are sensible people you respect on other topics, who have the opinion that there is room for behaviors other than CFS, and who have created a pluggable scheduler framework which they are trying to hand you on a platter. And you won't even consider that they might be right, because you believe there can be one scheduler which is close to optimal for all loads. 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. 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. 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. Why do people believe that desktop doesn't have multiple processors or through-put intensive loads? Why are people continuing this *idiotic* scheduler discussion? Because people can't get you to understand that one size doesn't fit all (and I doubt I've broken through). 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 real issue is that you can't imagine that people who don't share your opinion are not only wrong but don't understand the problem. You may be right, but when you say anyone who disagrees is wrong by definition, then you have lost sight of productive technical differences. When your arguments drop to personal attacks and rants it's time to look at your technical values. 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. Exactly, and I'm not the only one who doubts that more than one model would be useful. I'm sorry you can't see that about CPU schedulers as well. 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. I don't disagree with you
