[refpolicy] Question: and the policy grows...
Daniel J Walsh
dwalsh at redhat.com
Thu Mar 17 13:34:40 CDT 2011
-----BEGIN PGP SIGNED MESSAGE-----
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.
>>>> 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
>>> 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/
-----END PGP SIGNATURE-----
More information about the refpolicy