Hello, Let me apologize if this is the wrong place to ask this question, but I figure that those well versed in SELinux can help me. I have been reading a ton about SELinux and Flask, and I haven't found anything that answered my question.
I am working on creating a security policy from scratch and followed the tutorial the IBM published ( http://www-128.ibm.com/developerworks/linux/library/l-selinux.html). After taking a look at the bare bones policy.conf file it generated, it got me thinking- I don't need to have something as granular as SELinux allows me to be. In fact it would simplify things if I could change the granularity. How would SELinux be affected if I were to remove some of the class definitions and took anything that referred to those classes out of my policy? Would SELinux just not enforce anything on those types of objects, would SELinux completely disallow all use of those objects or would it just break SELinux?
Thank you for your time and help, Rebecca
On Fri, 2007-01-26 at 12:18 -0500, bx wrote:
Hello, Let me apologize if this is the wrong place to ask this question, but I figure that those well versed in SELinux can help me. I have been reading a ton about SELinux and Flask, and I haven't found anything that answered my question.
I am working on creating a security policy from scratch
I'd suggest leveraging the reference policy instead as a baseline, then customize it as desired. http://oss.tresys.com/projects/refpolicy
and followed the tutorial the IBM published (http://www-128.ibm.com/developerworks/linux/library/l-selinux.html). After taking a look at the bare bones policy.conf file it generated, it got me thinking- I don't need to have something as granular as SELinux allows me to be. In fact it would simplify things if I could change the granularity. How would SELinux be affected if I were to remove some of the class definitions and took anything that referred to those classes out of my policy? Would SELinux just not enforce anything on those types of objects, would SELinux completely disallow all use of those objects or would it just break SELinux?
At present, removing kernel classes would lead to permission denials or breakage. See the thread starting with: http://marc.theaimsgroup.com/?l=selinux&m=116499002502432&w=2
Note however this isn't just a matter of granularity of protection, but rather completeness of protection; if you were to disable SELinux enforcement for a given object class, then you are removing all control on those objects, enabling them to serve as a way of bypassing policy. Changing the granularity of protection would just mean folding multiple classes together, e.g. handle all of the file-related classes as one, which you can achieve in policy by use of macros rather than needing to change the kernel.
On 1/26/07, Stephen Smalley sds@tycho.nsa.gov wrote:
I'd suggest leveraging the reference policy instead as a baseline, then
customize it as desired. http://oss.tresys.com/projects/refpolicy
I took a look at the reference policy and I am not sure how it can help
me. I am not trying to use SELinux to constrain programs and daemons to sandboxes, instead I would like to use it to create restricted system administrator accounts. Although in the future, I may want to end up hardening apache, etc, however at this point, that is not my focus. My approach would be similar to the targeted policy, in which there is an "unconfined" base domain in which most things roam. I understand that in theory the reference policy would be a good approach due to its modular approach, however I do not know where to start to get myself my base unconfined layer I want. I am open to suggestions.
At present, removing kernel classes would lead to permission denials or breakage. See the thread starting with: http://marc.theaimsgroup.com/
?l=selinux&m=116499002502432&w=2
Note however this isn't just a matter of granularity of protection, but rather completeness of protection; if you were to disable SELinux enforcement for a given object class, then you are removing all control on those objects, enabling them to serve as a way of bypassing policy. Changing the granularity of protection would just mean folding multiple classes together, e.g. handle all of the file-related classes as one, which you can achieve in policy by use of macros rather than needing to change the kernel.
This makes absolute sense, thank you. I will use macros to create the granularity I desire.
I appreciate your help, Rebecca
On Fri, 2007-01-26 at 15:34 -0500, bx wrote:
On 1/26/07, Stephen Smalley sds@tycho.nsa.gov wrote: I'd suggest leveraging the reference policy instead as a baseline, then customize it as desired. http://oss.tresys.com/projects/refpolicy
I took a look at the reference policy and I am not sure how it can help me. I am not trying to use SELinux to constrain programs and daemons to sandboxes, instead I would like to use it to create restricted system administrator accounts. Although in the future, I may want to end up hardening apache, etc, however at this point, that is not my focus. My approach would be similar to the targeted policy, in which there is an "unconfined" base domain in which most things roam. I understand that in theory the reference policy would be a good approach due to its modular approach, however I do not know where to start to get myself my base unconfined layer I want. I am open to suggestions.
All policies are built from the reference policy these days, including the Fedora -targeted policy (and the -strict policy and the -mls policy). They are just different configurations of it. -strict policy has a notion of user roles already, whereas -targeted does not (at present).
On Fri, 2007-01-26 at 12:18 -0500, bx wrote:
I am working on creating a security policy from scratch and followed the tutorial the IBM published (http://www-128.ibm.com/developerworks/linux/library/l-selinux.html). After taking a look at the bare bones policy.conf file it generated, it got me thinking- I don't need to have something as granular as SELinux allows me to be. In fact it would simplify things if I could change the granularity. How would SELinux be affected if I were to remove some of the class definitions and took anything that referred to those classes out of my policy? Would SELinux just not enforce anything on those types of objects, would SELinux completely disallow all use of those objects or would it just break SELinux?
Assuming you are talking about the definition of classes and permissions in policy/flask/* pretty much it would just break. The class and permission definitions from policy and the kernel are supposed to match. Recent kernel changes (2.6.18 and later I belive) have allowed policy to load which does not define all of the classes and permissions defined in the kernel, but it still enforces decisions over those classes and permissions. Since there cannot be any allow rules for those classes in the policy everything gets denied.
I still have an old half baked patch which allows the policy to decide if it wants to enforce decisions on undefined classes and permissions but I haven't had time to make it work according to all the suggestions I received when I submitted it. So for now, you pretty much just have to use them all.
-Eric
On Fri, 2007-01-26 at 12:50 -0500, Eric Paris wrote:
On Fri, 2007-01-26 at 12:18 -0500, bx wrote:
I am working on creating a security policy from scratch and followed the tutorial the IBM published (http://www-128.ibm.com/developerworks/linux/library/l-selinux.html). After taking a look at the bare bones policy.conf file it generated, it got me thinking- I don't need to have something as granular as SELinux allows me to be. In fact it would simplify things if I could change the granularity. How would SELinux be affected if I were to remove some of the class definitions and took anything that referred to those classes out of my policy? Would SELinux just not enforce anything on those types of objects, would SELinux completely disallow all use of those objects or would it just break SELinux?
Assuming you are talking about the definition of classes and permissions in policy/flask/* pretty much it would just break. The class and permission definitions from policy and the kernel are supposed to match. Recent kernel changes (2.6.18 and later I belive) have allowed policy to load which does not define all of the classes and permissions defined in the kernel, but it still enforces decisions over those classes and permissions. Since there cannot be any allow rules for those classes in the policy everything gets denied.
I still have an old half baked patch which allows the policy to decide if it wants to enforce decisions on undefined classes and permissions but I haven't had time to make it work according to all the suggestions I received when I submitted it. So for now, you pretty much just have to use them all.
Yep, and all of patches to date only allow for the case where new classes or permissions at the end of the lists are omitted (e.g. for kernels with new classes or perms not yet defined by the current policy), not for arbitrary creation of "holes" in the class or permission mappings (i.e. if you remove a class from anywhere but the end, then policy definitions will end up with subsequent classes off-by-one from the expected values by the kernel, and that should always be rejected by the kernel).
selinux@lists.fedoraproject.org