From: dwalsh@redhat.com (Daniel J Walsh)
Date: Thu, 17 Mar 2011 10:25:29 -0400
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <1300369855.30425.14.camel@tesla.lan>
References: <1300369855.30425.14.camel@tesla.lan>
Message-ID: <4D8219D9.7080504@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

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
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

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.

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

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

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

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2CGdkACgkQrlYvE4MpobOi4ACeMEu26NsyLuMBf2RA20T2ULMg
8K0An0TlyQzP7KBvEF2HV1Wb2rHXU+SY
=Vo9d
-----END PGP SIGNATURE-----