From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Thu, 17 Mar 2011 22:34:52 +0100
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <1300396124.31755.48.camel@tesla.lan>
References: <1300369855.30425.14.camel@tesla.lan> <4D8219D9.7080504@redhat.com>
	<1300377867.30425.40.camel@tesla.lan> <4D823A60.9020107@redhat.com>
	<1300390804.31755.6.camel@tesla.lan>
	<20110317202433.GA6695@siphos.be>
	<1300396124.31755.48.camel@tesla.lan>
Message-ID: <20110317213452.GB6695@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, Mar 17, 2011 at 10:08:44PM +0100, Guido Trentalancia wrote:
> > The next step then - once a distribution has at least one policy that is
> > working well - is to offer the necessary documentation and help for
> > administrators to create and manage their own policies [1]. After all, if a
> > distribution only delivers the policy but offers little help to modify or
> > install your own, then the distributions' the security administrator and not
> > some team in the organization.
> 
> I think I got lost in the last sentence. But the documentation you
> describe is generic documentation about policy writing. So it's
> something that could be written once for everybody (ideally a joint
> effort).

True, but some distributions offer additional tools, methods or packages to
support administrators with SELinux.

> My question was more about methods for policy reduction and tightening
> (a policy management issue)... Can you think about solutions to that
> problem ?

I don't have a solution, but my suggestion would be to auditallow the
statements you believe are obsolete for a system and thoroughly test the
system and see if no audits occur.

If you'd like to have the obsoleted ones suggested rather than you having to
find some, perhaps there is a way to regularly dump the avc cache and after
some time, correlate the dumps with the policy, informing the developer
about rules that were potentially never hit during the test. 

Little change in method, same principle.

But honestly, I would hope that software developers for which a SELinux
policy (module) exists would maintain it as part of their stack, rather than
rely on people like you to debug, test and suggest updates on the policies.

Wkr,
	Sven Vermeulen