From: guido@trentalancia.com (Guido Trentalancia)
Date: Thu, 17 Mar 2011 21:27:50 +0100
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <4D826724.4030908@redhat.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>
	<4D826724.4030908@redhat.com>
Message-ID: <1300393670.31755.24.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, 17/03/2011 at 15.55 -0400, Daniel J Walsh wrote:
> On 03/17/2011 03:40 PM, Guido Trentalancia wrote:
> >>> > > 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.
> >> > 
> >>> > > 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.
> >>> > > 
> >>> > > I'd be very happy to hear from others...
> >>> > > 
> >>> > > Regards,
> >>> > > 
> >>> > > Guido
> >>> > > 
> >> > I think if we ever get to the next generation of policy and could start
> >> > removing rules. easily this would help.
> > I didn't get this. What could help ?
> > 
> 
> Right now removing access is difficult, you really need to be able to
> start with the entire policy and build.  If we improved the tool chain,
> you could remove rules.  Then people could experiment with removing
> rules and it the system still works, suggest patches that remove allow
> rules.

Trial and error. Can you think of anything else behind that ? Or
otherwise just confirm that anything else is impossible to achieve ?

Because you know, automated trial and error methods are easy, cheap and
usually quite powerful. But human trial and error can be quite expensive
in practice.

> Imagine you could write policy module that said
> 
> remove  application_domain user_tty_device_t:chr_file open;
> 
> [SNIP]

Yes. I get the point. The operator "remove" always having precedence
over "add". Hopefully we'll have that one day. In the end it shouldn't
be too hard to implement...

You found 1 methodology.

Regards,

Guido