From: guido@trentalancia.com (Guido Trentalancia)
Date: Thu, 17 Mar 2011 21:15:41 +0100
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <4D824AC3.4070502@tresys.com>
References: <1300369855.30425.14.camel@tesla.lan>
	<4D8219D9.7080504@redhat.com> <1300377867.30425.40.camel@tesla.lan>
	<4D823A60.9020107@redhat.com>  <4D824AC3.4070502@tresys.com>
Message-ID: <1300392941.31755.17.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, 17/03/2011 at 13.54 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 12:44, Daniel J Walsh wrote:
> > On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> >> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
> >>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:

[cut]

> >>> But it is very difficult to remove access that was granted, since no one
> >>> wants more bugs.
> > 
> >> There might be environments where a (temporary) bug is always preferable
> >> than a looser policy...
> > 
> > Well as long as the temporary bug does not cause someone to disable SELinux.
> 
> I think this is the biggest thing point.  We've worked hard over many
> years to get to a condition where the policy could be used by everyday
> users.  Do we want a tighter policy?  Absolutely.  Is there cruft in the
> policy?  Absolutely.  I always push for more documentation so that if
> something changes with a particular app that rules could be removed, but
> most lines in Refpolicy lack a explanation/justification.
> 
> For cases on higher assurance systems, where they do care more about
> eliminating this type of access, there is usually rigorous testing
> involved already and they have a fairly static configuration.  We can't
> get an sufficient amount of testing for Refpolicy and the below point is
> why.
> 
> >> In any case, we haven't found a solution (or at least a methodology).
> >> The only (obvious) one I can foresee at the moment is periodically
> >> restarting from scratch (i.e. creating a new generation of refpolicy
> >> from scratch every x years). Which is massive work.
> > 
> > Yes and going to generate a large amount of errors, since most bugs are
> > caused by running apps in different ways.
> 
> Definitely.  This is probably the biggest issue that we face in
> maintaining policy.  People do all sorts of things to their systems,
> changing configurations and relocating files, etc.

Relocating files is not a problem because the file context could be just
copied off 1:1 from one generation to the next one.

But yes, of course, no doubt it's massive work. One could still rewrite
one module at a time.

But anyway, I was expecting to hear about alternative solutions to
that... For example, Dan proposed to use setools for certain kind of
analysis.

> >> From the Changelog I take that refpolicy started on June 2005. Software
> >> version numbers does not necessarily mean anything, but just to give an
> >> idea, on June 2005, we had the following versions (taken at random):
> > 
> >> kernel 2.6.12 (now 2.6.38)
> >> Linux-PAM 0.79 (now 1.1.3)
> >> gtk+ 2.6.8 (now 3.0)
> >> evolution 2.3.3 (now 2.32.2)
> >> ...
> > And refpolicy was an attempt to make all rules == example policy when
> > the port happened, so most of the original rules come from Prior to 2002.
> 
> Right.  There was ~6 years of policy development that happened before
> Refpolicy started and we didn't want to lose the effort that went into
> it.  The idea being that after a rigorous structure was applied, there
> is a better chance of identifying excessive permissions.  That did
> happen, and we did remove a lot of policy.  But its hard finding the
> little excessive bits that are sprinkled around the policy.

So when did that happen last ?

And yes, the little excessive bits. Any idea on a method to help
spotting that out ?

Regards,

Guido