From: dac.override@gmail.com (Dominick Grift) Date: Sun, 14 Aug 2016 22:43:51 +0200 Subject: [refpolicy] [PATCH] Allow dbus to execute binaries In-Reply-To: <96ccc8e7-fa70-f157-9de8-d6993813a52f@gmail.com> References: <395201837.942692.1471122911126.JavaMail.open-xchange@popper02.register.it> <1471203435.27146.24.camel@trentalancia.net> <338505048.945576.1471205117819.JavaMail.open-xchange@popper02.register.it> <777e45c9-3352-8380-fbbd-3b9d11a185b6@gmail.com> <76179484.945599.1471206066729.JavaMail.open-xchange@popper02.register.it> <96ccc8e7-fa70-f157-9de8-d6993813a52f@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/14/2016 10:28 PM, Dominick Grift wrote: > On 08/14/2016 10:21 PM, Guido Trentalancia wrote: >> Hello Dominick ! >> >>> On the 14th of August 2016 at 22.10 Dominick Grift >>> wrote: >>> >>> >>> On 08/14/2016 10:05 PM, Guido Trentalancia wrote: >>>> Hello Dominick. >>>> >>>>> On the 14th August 2016 at 21.40 Dominick Grift >>>>> wrote: >>>>> >>>>> >>>>> On 08/14/2016 09:37 PM, Guido Trentalancia wrote: >>>>>> On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote: >>>>>>> On 08/13/2016 11:15 PM, Guido Trentalancia wrote: >>>>>>>> Update for the dbus module so that it can start. >>>>>>> >>>>>>> What binary are you referring to? >>>>>> >>>>>> Apparently it tries to execute /bin/false. If it fails, it refuses to >>>>>> start. >>>>>> >>>>> >>>>> Oh sorry i overlooked this reply. I can't reproduce this. Please >>>>> reproduce and enclose the avc denial. This shouldnt be needed in my >>>>> experience. >>>> >>>> type=AVC msg=audit(1471048594.845:72): avc: denied { execute } for >>>> pid=2075 >>>> comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337 >>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>>> tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0 >>>> type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e syscall=59 >>>> success=no >>>> exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0 ppid=2074 pid=2075 >>>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 >>>> tty=(none) ses=4294967295 comm="dbus-daemon-lau" >>>> exe="/usr/libexec/dbus-daemon-launch-helper" >>>> subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) >>>> >>>> I am not happy to add the permission, but unfortunately, if it refuses to >>>> start, >>>> I can't see other choices. >>>> >>> >>> I can, but it is not pretty. >>> >>> We should target /usr/libexec/dbus-daemon-launch-helper >>> >>> You see if you now allow system_dbus_t then we get into issues later >>> because dbus can be used to start daemons. So we risk daemons ending up >>> trying to run in the system_dbus_t domain, and if we arent paying >>> attention that might lead us to associate permisisons to system_dbus_t >>> that arent actually needed by dbus but instead are needed for some >>> daemon started by dbus >> >> Do you want to propose an alternative patch ? > > Yes /usr/libexec/dbus-daemon-launch-helper should be targeted in a > separate domain, probably a init_system_domain() assuming that its > started by init. > By the way. I know that it must test your patience as well. I think I know how you might feel (I've been there as well). Submitting revision following revision etc. Just know that these reviews/rewrites will eventually pay off. It will make you better, and that will make writing good policy easier. It is appreciated! I will not be able to write a solid policy for /usr/libexec/dbus-daemon-launch-helper because my system does not use it. so i will not be able to easily produce it. >> >>>>>>>> Signed-off-by: Guido Trentalancia >>>>>>>> --- >>>>>>>> policy/modules/contrib/dbus.te | 1 + >>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>> >>>>>>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te >>>>>>>> 2016-08-06 >>>>>>>> 21:27:11.344094223 +0200 >>>>>>>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20 >>>>>>>> 16-08-13 >>>>>>>> 13:20:54.013168684 +0200 >>>>>>>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_ >>>>>>>> corecmd_list_bin(system_dbusd_t) >>>>>>>> corecmd_read_bin_pipes(system_dbusd_t) >>>>>>>> corecmd_read_bin_sockets(system_dbusd_t) >>>>>>>> +corecmd_exec_bin(system_dbusd_t) >>>>>>>> corecmd_exec_shell(system_dbusd_t) >>>>>>>> >>>>>>>> dev_read_urand(system_dbusd_t) > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/651d1f22/attachment.bin