From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 01 Mar 2011 23:47:27 +0100
Subject: [refpolicy] [PATCH 18/34]: patch for the policykit module
 (labeling, start from dbus, read xdm files)
In-Reply-To: <4D6D4500.2080508@tresys.com>
References: <1297837325.3205.75.camel@tesla.lan>
	<4D6BA982.6070101@tresys.com> <1298920070.3123.9.camel@tesla.lan>
	<4D6D4500.2080508@tresys.com>
Message-ID: <1299019647.14035.81.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

Anyway, at the moment I cannot test, but I will let you know as soon as
possible. If you really want to go for that solution, there are good
chances that it can be done because there are good chances that this is
not critical for policykit.

If in the meanwhile you want to have a closer look at the cause, then
please fetch policykit versions 0.99 and 0.100 (latest). It's polkitd
(it has a separate directory and it's just a couple of short source
files).

Regards,

Guido