On Thu, Jul 16, 2020 at 9:36 AM Mike Palmiotto <mike.palmiotto@xxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 16, 2020 at 8:40 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Wed, Jul 15, 2020 at 6:45 PM Mike Palmiotto > > <mike.palmiotto@xxxxxxxxxxxxxxx> wrote: > > > Interestingly, the test program is working fine: > > > https://github.com/mpalmi/selinux/tree/sestatus > > > https://github.com/mpalmi/sestatus-test > > > > > > On a test run, I'm seeing both the status page and netlink socket > > > notifications for load_polcy (twice for each case): > > > > > > ``` > > > ./test > > > opened avc successfully > > > got netlink socket: 4 > > > > > > watching netlink socket for events > > > avc: received policyload notice (seqno=3) > > > policy reload notice received > > > avc: received policyload notice (seqno=4) > > > policy reload notice received > > > ^C > > > watching sestatus page for events > > > avc: received policyload notice (seqno=5) > > > policy reload notice received > > > avc: received policyload notice (seqno=6) > > > policy reload notice received > > > ^Cclosing netlink socket: 4 > > > destroying avc > > > goodbye > > > ``` > > > > > > Still seeing the MAC_POLICY_LOAD audit message, but none of the usual > > > USER_AVC policyload notices. > > > > I only see one notification per load_policy invocation. > > I meant I ran load_policy twice for netlink and then twice for > sestatus. You're correct, there is only one notification per > invocation. > > > What versions of kernel and dbus are you using? Are you using dbus-daemon or > > dbus-broker? How are you testing dbus with this change - just doing a > > make install relabel of libselinux and restarting dbus-daemon or > > dbus-broker, then running load_policy and checking for USER_AVC > > messages? Is this on CentOS 7/8? > > Here's my setup: > > [vagrant/staff_r/SystemLow@mls:~]$ uname -r > 4.18.0-193.el8.x86_64 > [vagrant/staff_r/SystemLow@mls:~]$ cat /etc/redhat-release > Red Hat Enterprise Linux release 8.2 (Ootpa) > [vagrant/staff_r/SystemLow@mls:~]$ dbus-daemon --version | head -1 > D-Bus Message Bus Daemon 1.12.8 > [vagrant/staff_r/SystemLow@mls:~]$ systemctl status --no-pager dbus --full > ● dbus.service - D-Bus System Message Bus > Loaded: loaded (/usr/lib/systemd/system/dbus.service; static; > vendor preset: disabled) > Active: active (running) since Thu 2020-07-16 01:19:31 UTC; 47min ago > Docs: man:dbus-daemon(1) > Main PID: 865 (dbus-daemon) > Tasks: 1 (limit: 11480) > Memory: 3.6M > CGroup: /system.slice/dbus.service > └─865 /usr/bin/dbus-daemon --system --address=systemd: > --nofork --nopidfile --systemd-activation --syslog-only > > This is my test thread: > > 1) `make clean distclean` > 2) `sudo make DEBUG=1 LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install > install-pywrap relabel -s` > 3) `sudo restorecon -RF /` (mcstrans apparently doesn't have the > relabel target -- I should submit a patch for that) > 5) reboot > 6) load_policy/setenforce/setsebool and look for USER_AVC notices in audit.log > > Please let me know if there's any other information you need. I'm > still trying to track this down on my end. I will probably build dbus > with debugging and take a look at what's going on. That version of dbus did not call avc_netlink_acquire_fd(). It only calls avc_init() with a thread callback, with the expectation that avc_init() will create the thread (as it did prior to your patch). So you can't move that part. Not sure what happens if you leave it there. If you can't make it work cleanly with legacy object managers, then I guess we can go with the opt-in route.
