From: guido@trentalancia.com (Guido Trentalancia)
Date: Wed, 02 Mar 2011 20:55:58 +0100
Subject: [refpolicy] [PATCH 18/34]: patch for the policykit module
 (labeling, start from dbus, read xdm files)
In-Reply-To: <4D6E4B6A.5090708@tresys.com>
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>
	<4D6E4B6A.5090708@tresys.com>
Message-ID: <1299095758.28492.20.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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 I will check if it is critical to normal policykit operation as soon
as possible.

Regards,

Guido