From: dwalsh@redhat.com (Daniel J Walsh)
Date: Thu, 17 Mar 2011 14:34:40 -0400
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: <4D825440.6070207@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2011 01:54 PM, 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:
> 
>>>> 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.
> 
> 
I am experimenting with this now.  But it would be good if we could
agree on the terminology.

rw_inherited_term_perms is what I am calling it.

And

userdom_use_inherited_term
terminal_use_all_inherited_terminals


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2CVDwACgkQrlYvE4MpobPfHQCgnhMiZojP9COPITBtIpTaMK5/
yH4AoLsejYUDEHf+NwYiGMUPzE6PcSI+
=MZ7/
-----END PGP SIGNATURE-----