From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 17 Mar 2011 13:54:11 -0400
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <4D823A60.9020107@redhat.com>
References: <1300369855.30425.14.camel@tesla.lan>		<4D8219D9.7080504@redhat.com>
	<1300377867.30425.40.camel@tesla.lan> <4D823A60.9020107@redhat.com>
Message-ID: <4D824AC3.4070502@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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:

>>> For example, we have lots of code that allows confined applications to
>>> open terminals.  I would bet that almost no confined processes ever open
>>> a terminal.  And yet the ability to open a terminal can give you a
>>> communications channel to attack other confined processes or even the
>>> confined user.

Get me a set of patches that fixes that, and I'll be glad to merge it.


>>> 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.

>> 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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com