SELinux Policy/Flask Classes from scratch

[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