Re: [gentoo-hardened] SELinux policy rules principles?

[Chris Richards <gizmo@giz-works.com>]

On 01/16/2011 09:09 AM, Sven Vermeulen wrote:
> Hi all,
>
> When writing security policies, it is important to first have a vision on
> how the security policies should be made. Of course, final vision should be
> with a systems' security administrator, but a distribution should give a
> first start for this.
>
> For the time being, Gentoo Hardened's policies are based upon the reference
> policy's implementation, but I can imagine that this will evolve further.
> The moment however we start adding policies ourselves (outside simple
> patching of the reference policy's implementation) we need to have some
> rules on what or how our rules should be made.
>
> One first principle that we might need to discuss about is what we want to
> allow in our policy. Do we want to allow all normal behavior (i.e. you use
> an application or server the way it is meant to and we make sure no denials
> are generated for this) but shield off abnormal behavior as much as possible
> (by rightly aligning domains and types)? Or do we want to allow just enough
> so that the applications function properly during regular operations,
> causing various denials to be in place still?
My general feeling is that the system should operate FROM THE USER 
PERSPECTIVE the way it always does, i.e. the existence of SELinux should 
be relatively transparent to the user and/or administrator, at least to 
the extent that is practical.  There may be some things that you simply 
can't avoid changing, but they should generally be few and far between.
> And if we would opt for the latter, do we want to dontaudit those denials to
> keep the logging clean, or do we then expect the administrator to manage his
> own dontaudits?
>
My general feeling here is that, again where practical, we should avoid 
cluttering the logs.  Logs that are cluttered with noise don't get 
properly evaluated for the truly exceptional conditions that the 
administrator needs to be concerned about.  Obviously, there are tools 
that can help with this, but those tools should be used for the purpose 
of helping the administrator organize the information, not prune the 
logs of stuff to ignore.  If there's stuff that is going to be routinely 
ignored because it is essentially useless chatter, then it shouldn't be 
there to start with.

Those are just my thoughts.  Others who know more than I may have a 
different opinion.

Later,
Chris