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

Hello Dan,

thanks very much for getting back !

On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
> > Hello everybody !
> > 
> > I have a question which I believe is quite interesting.
> > 
> > I often get on and off the list because of a lack of time, but I have
> > noticed that most (if not all) of the patches that have been submitted
> > to refpolicy in the last period of time, including a few patches that I
> > have submitted, were intended to improve usability and were going to add
> > new permissions to this or that policy module (it's always diff +).
> > 
> > So, the policy grows... and becomes weaker (less tight and secure),
> > although hopefully more usable.
> > 
> > If this trends continues the policy will just become weaker and weaker
> > with time and this might not always be backed by an increased usability.
> > 
> > I would even expect that some of the permissions added long time ago and
> > still present in the policy are no longer needed by more recent versions
> > of the same packages. And usually backwards compatibility (for very old
> > package versions) is not something which should be guaranteed forever...
> > 
> > So my question is: who is going to take care of periodically trimming
> > down the permissions in refpolicy that are no longer needed (keep the
> > policy tight) ? But more importantly how is this going to be done
> > technically (the methodology) ?
> > 
> > Thanks for your time !
> > 
> > Regards,
> > 
> > Guido
> > 
> Great question.  I think one problem we have is that refpolicy is a one
> size fits all system.  Upstream has decided to maintain policy in such a
> way that it would continue to work on Ancient distributions (RHEL4),  So
> removing Access could break older distributions.
> 
> On thing that refpolicy has not adopted is the use of inherited file
> descriptors versus files descriptors opened by applications.
> 
> 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.

Great example.

> If  you put the prompt passwd: in front of me in a terminal, my fingers
> will type my password before my brain can stop them.  :^)

That's too true !

> Why not remove open from all tty handling.  Then confined apps can only
> use ttys that are passed to them from parent processes.

Good idea. But will that always be applicable (without changing the
application or imposing anything to application developers) ?

> Another big change I have put into Fedora policy is the ability to turn
> off access to ldap for apps that need auth_use_nsswitch().  (Which turns
> out to be just about all confined domains.)
> 
> getsebool -a | grep ldap
> authlogin_nsswitch_use_ldap --> on

Yes, I know Redhat is privately putting some effort into tightening
permissions. Although, at a first sight, the overall ratio "+" over "-"
appeared to me always much greater than 1.

> On RHEl6 and all Fedoras you can do this even if the system is using
> ldap for passwd, since Fedora and RHEL6 use sssd for authorization and
> passwd now.
> 
> Other cleanups like turning off unlabelednet.pp, unconfined.pp, While
> leaving unconfined_t users, cleaning up corenet_*_all_nodes and
> corenet_*all_if need to be done.
> 
> 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...

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.

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

I'd be very happy to hear from others...

Regards,

Guido