SELinux Policy/Flask Classes from scratch

[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