From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 02 Mar 2011 08:51:38 -0500
Subject: [refpolicy] [PATCH 18/34]: patch for the policykit module
 (labeling, start from dbus, read xdm files)
In-Reply-To: <1299019647.14035.81.camel@tesla.lan>
References: <1297837325.3205.75.camel@tesla.lan>	 <4D6BA982.6070101@tresys.com>
	<1298920070.3123.9.camel@tesla.lan>	 <4D6D4500.2080508@tresys.com>
	<1299019647.14035.81.camel@tesla.lan>
Message-ID: <4D6E4B6A.5090708@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 03/01/11 17:47, Guido Trentalancia wrote:
> On Tue, 01/03/2011 at 14.12 -0500, Christopher J. PeBenito wrote:
>> On 02/28/11 14:07, Guido Trentalancia wrote:
>>> On Mon, 28/02/2011 at 08.56 -0500, Christopher J. PeBenito wrote:
>>>> On 02/16/11 01:22, Guido Trentalancia wrote:
>>>>> This patch adds a file context for the /var/lib/polkit-1 directory.
>>>>> It then allows policykit to be started from dbus. It also adds
>>>>> some other permissions needed to run policykit and a new interface
>>>>> which is used to read xdm files.
>>>>>
>>>>> diff -pruN refpolicy-git-02022011-test-apply2/policy/modules/services/policykit.fc refpolicy-git-02022011-test-apply3/policy/modules/services/policykit.fc
>>>>> --- refpolicy-git-02022011-test-apply2/policy/modules/services/policykit.fc	2011-01-08 19:07:21.280747356 +0100
>>>>> +++ refpolicy-git-02022011-test-apply3/policy/modules/services/policykit.fc	2011-02-07 03:31:53.547856778 +0100
>>>>> @@ -11,5 +11,6 @@
>>>>>  /var/lib/misc/PolicyKit.reload			gen_context(system_u:object_r:policykit_reload_t,s0)
>>>>>  /var/lib/PolicyKit(/.*)?			gen_context(system_u:object_r:policykit_var_lib_t,s0)
>>>>>  /var/lib/PolicyKit-public(/.*)?			gen_context(system_u:object_r:policykit_var_lib_t,s0)
>>>>> +/var/lib/polkit-1(/.*)?				gen_context(system_u:object_r:policykit_var_lib_t,s0)
>>>>>  /var/run/PolicyKit(/.*)?			gen_context(system_u:object_r:policykit_var_run_t,s0)
>>>>>  
>>>>> diff -pruN refpolicy-git-02022011-test-apply2/policy/modules/services/policykit.te refpolicy-git-02022011-test-apply3/policy/modules/services/policykit.te
>>>>> --- refpolicy-git-02022011-test-apply2/policy/modules/services/policykit.te	2011-02-07 03:31:24.763790944 +0100
>>>>> +++ refpolicy-git-02022011-test-apply3/policy/modules/services/policykit.te	2011-02-07 03:31:53.550857306 +0100
>>>>> @@ -35,8 +35,8 @@ files_pid_file(policykit_var_run_t)
>>>>>  # policykit local policy
>>>>>  #
>>>>>  
>>>>> -allow policykit_t self:capability { setgid setuid };
>>>>> -allow policykit_t self:process getattr;
>>>>> +allow policykit_t self:capability { setgid setuid sys_ptrace };
>>>>
>>>> This sys_ptrace is highly questionable.
>>>
>>> Could that be due to calls to the following functions:
>>>
>>> sigemptyset()
>>> sigaddset()
>>> sigprocmask()
>>>
>>> There are no calls to ptrace() and this is not due to
>>> reading /proc/PID/cmdline.
>>>
>>> In truth I can only check if this is critical for policykit.
>>
>> dontauditing this doesn't work?
> 
> dontaudit will just shut it up. If it is not critical we could do that,
> but *what's the point of hiding stuff under the carpet* ?
>
> Your reply "[PATCH 11/34]: patch to allow consolekit shutdown the
> system" timestamped Tue, 01 Mar 2011 14:18:01 -0500 gives a practical
> example of the fact that dontaudit can have side effects even for a
> maintainer.
> 
> If one works everyday with the policy such side effects probably have a
> minimal impact because, as soon as something goes wrong, he or she knows
> that if there are no AVCs then he or she has to track down the dontaudit
> rules.
> 
> But for somebody that barely knows his or her system has a security
> framework and a security policy, these "side-effects" could turn into
> real "blockers". For example, he or she manages to find out that the
> problem is due to SELinux, then manages to find out that he/she needs to
> check the audit logs, but at the end he/she doesn't find anything there
> and just gets confused.
> 
> For a distribution it's different. Everything is pre-packaged and
> tested. But here we are discussing the reference policy.
> 
> In the context of the reference policy it could make some sense only in
> the context of well known "leaks". But this doesn't appear to be the
> case...

In general, anything that is not required should be denied.  We do not
want to fill up the logs with extraneous denial messages, so we
dontaudit them.  If there is a question of denials being suppressed by
dontaudits, thats why we have semodule -D.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com