SELinux Policy/Flask Classes from scratch

[bx]

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

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency

[Eric Paris]

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

[bx]

On 1/26/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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

[Stephen Smalley]

On Fri, 2007-01-26 at 15:34 -0500, bx wrote:
>  On 1/26/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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).

-- 
Stephen Smalley
National Security Agency

[Stephen Smalley]

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

-- 
Stephen Smalley
National Security Agency