[refpolicy] [PATCH 18/34]: patch for the policykit module (labeling, start from dbus, read xdm files)

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 3/2/2011 2:55 PM, Guido Trentalancia wrote:
> On Wed, 02/03/2011 at 08.51 -0500, Christopher J. PeBenito wrote:
>> 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.
>
> I forgot to add that it's not flooding logs. It logs that only once upon
> starting up.

But if we didn't dontaudit things like this, the log might be flooded.

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