From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 03 Mar 2011 08:28:27 -0500 Subject: [refpolicy] [PATCH 18/34]: patch for the policykit module (labeling, start from dbus, read xdm files) In-Reply-To: <1299095758.28492.20.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> <4D6E4B6A.5090708@tresys.com> <1299095758.28492.20.camel@tesla.lan> Message-ID: <4D6F977B.8020701@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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