Hide Forgot
Description of problem: If a 5.7 machine has ypserv running but not ypbind, then the following will cause AVC denials: dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig This snippet is used in post-install/uninstall sections of a few spec files to ensure dbus configs get reloaded. It appears that ypbind has logic in its init.d script to ensure that allow_ypbind selinux boolean is set properly. I tried looking for whatever's making dbus call ypbind on a machine with only ypserv installed, but I was unable to find it. Version-Release number of selected component (if applicable): dbus-1.1.2-15.el5_6 dbus-glib-0.73-10.el5_5 dbus-libs-1.1.2-15.el5_6 dbus-python-0.70-9.el5_4 dbus-x11-1.1.2-15.el5_6 ypbind-1.19-12.el5 ypserv-2.19-5.el5 How reproducible: every time Steps to Reproduce: 1. start with a fresh machine, and install ypbind and ypserv 2. configure the domainname for ypserv 3. start ypserv 4. run the aforementioned dbus command Actual results: AVC denials Expected results: No AVC denials Additional info: This came up during TPS testing of subscription-manager, which relies on reloading the dbus config as a fix for 693896.
Hi Chris, I've tested this issue in many scenarios and this is what I found: The steps to reproduce from comment #1 didn't work for me, while I didn't see any AVC denials using ypserv configured alone (and ypbind disabled). However I could reproduce it when I tried to start ypbind, which had been binded to a server, that didn't serve the NIS services (e.g. localhost without ypserv running). If I boot with ypbind disabled, there is no problem with the dbus-send command (it doesn't matter how allow_ypbind is set). Then, after trying to start ypbind daemon (which fails because there is no server running), the dbus-send command triggers AVC denial messages, but only allow_ypbind is set to 0. So it seems like there is "something" (somewhere) changed in the system even if ypbind wasn't started correctly. Nevertheless, I haven't found a problem in ypbind yet, while the daemon seems to be always finished correctly (portmap binding too). But generally, if I have ypbind configured to start on boot, shouldn't the allow_ypbind be enabled every time in this case? Example of my AVC denial messages (hope they are the same as yours): type=AVC msg=audit(1303146131.442:56): avc: denied { name_connect } for pid=1816 comm="dbus-daemon" dest=111 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1303146131.442:56): arch=c000003e syscall=42 success=no exit=-13 a0=18 a1=7ffff623ff10 a2=10 a3=2 items=0 ppid=1 pid=1816 auid=4294967295 uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 tty=(none) comm="dbus-daemon" exe="/bin/dbus-daemon" subj=system_u:system_r:system_dbusd_t:s0 key=(null)
Please, see bug #474187, too. There is a similar issue discussed and it seems that setting setsebool -P allow_ypbind=1 permanently can be good enough in this case.
Jan, I am going to unlink this bug from mine, since a workaround is provided. Thanks!
That's good news, Chris, so I'm closing this as a notabug, too.