From: guido@trentalancia.com (Guido Trentalancia)
Date: Fri, 18 Mar 2011 16:20:13 +0100
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <4D836390.3030405@tresys.com>
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>
	<20110317213452.GB6695@siphos.be>  <4D836390.3030405@tresys.com>
Message-ID: <1300461613.4019.25.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, 18/03/2011 at 09.52 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 17:34, Sven Vermeulen wrote:
> > 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. 
> 
> This has been considered in the past.  The biggest problem is that if
> you don't exercise all of the code paths, especially the obscure error
> paths, you may be removing valid policy.

A magic solution to that class of problems does not exist. Similar
drawbacks exist when creating policy for a package that has been written
by somebody else. So there would still need to be some trial and error
part.

Nevertheless, in my opinion that solution is wonderful ! The best answer
I have received so far. A consistent and general methodology.

Regards,

Guido