[refpolicy] Question: and the policy grows...

[dwalsh@redhat.com (Daniel J Walsh)]

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

On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> 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...
> 
Well as long as the temporary bug does not cause someone to disable SELinux.

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

> 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.
> 
> I'd be very happy to hear from others...
> 
> Regards,
> 
> Guido
> 
I think if we ever get to the next generation of policy and could start
removing rules. easily this would help.

I think people going through with setools and looking for unexpected
allow rules would be helpful.

setools is a pretty good set of tools for analyzing policy.  If we could
get some people (college kids) to analyze the policy.  And then open
bugs where they think we have wholes.

# sesearch -A -t user_tty_device_t -p open | wc -l
254

On a system where unconfind.pp is disabled we still have 254 domains
that can open a users tty in Fedora 15

sesearch -A -t shadow_t -c file -p open  -C | grep -v ^D | wc -l
23

sesearch -A -t passwd_t -c process -p transition  | wc -l
13

I think getting people to go in and examine the policy and ask
questions, why do we have these rules would be helpful.  Maybe we setup
test days, or something to remove bogus policy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2COmAACgkQrlYvE4MpobN8XwCfbiWVCj23G00EG+0/1wi0Tj0s
RLMAoI80NQIjACI+MfCrhWBTuS8GUyB9
=8Ik6
-----END PGP SIGNATURE-----