From: guido@trentalancia.net (Guido Trentalancia) Date: Tue, 16 Aug 2016 17:29:12 +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: <1471361352.3698.12.camel@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dominick (and cc Christoper). I am dropping this patch as it currently is, because it exposes the system to security risks. On Sun, 14/08/2016 at 22.28 +0200, 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 > > gmail.com> > > > wrote: > > > > > > > > > On 08/14/2016 10:05 PM, Guido Trentalancia wrote: > > > > Hello Dominick. > > > > > > > > > On the 14th August 2016 at 21.40 Dominick Grift > > > > @gmail.com> > > > > > 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. It originates in the Exec field of the service files (/usr/share/dbus- 1/system-services/*.service). It is extremely easy to reproduce, just create an empty service file and add an Exec=/bin/false statement or whatever other binary you want to execute, then upon starting up dbus, the dbus-daemon-launch-helper tries to execute that ! The strange thing is that now, after testing it again, it does not prevent the system from starting up. Maybe there was something else preventing that... You see, some services that are executed through systemd are shipped with service files that bring the Exec field set to /bin/false, most probably because the Exec field is mandatory for dbus service files... I am now dropping this dbus patch, because corecmd_exec_bin() executes bin_t executable files BUT the resulting process runs in the system_dbusd_t ! Exactly as you forecasted, I think ! > > > > 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 Yes, I agree, it's very risky and it should be avoided at all cost. Thanks very much for spotting this problem ! > > 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. I'll see what I can do with some more time. It's not an urgent matter... > > > > > > > > > > Signed-off-by: Guido Trentalancia > > > > > > > et> > > > > > > > > --- > > > > > > > > ?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) Best regards, Guido