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

[Sven Vermeulen <sven.vermeulen@siphos.be>]

On Sun, Jan 16, 2011 at 11:06:47AM -0600, Chris Richards wrote:
> On 01/16/2011 09:09 AM, Sven Vermeulen wrote:
> > 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.
[... What to allow ...]
> 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.
[... What to hide ...]
> 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.

Well, I've taken the liberty of writing down a sort-of policy document in
which we can include our development principles and methods. The idea is
that both existing and new developers then know how to "include" their 
suggested changes and how to configure/design the added SELinux policy
rules.

The document: http://goo.gl/2U0Zr

I've included a few of the items we discussed already, but also added
two others ones (see the "No Role-Specific Domains" and "Only Reference
Policy Suggested Roles" rules).

It's a *discussion* document, I'm really open to (many) suggestions (and
enhancements ;-)

Wkr,
	Sven Vermeulen