Description of problem: With the introduction of Podman, the audit.log might be spammed with useless entries like these: type=USER_AVC msg=audit(1576478689.463:24230): pid=1349 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=178861 scontext=system_u:system_r:container_t:s0:c108,c999 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus" type=USER_AVC msg=audit(1576478703.606:24255): pid=1349 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=179219 scontext=system_u:system_r:container_t:s0:c432,c636 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus" type=USER_AVC msg=audit(1576478739.451:24300): pid=1349 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=179920 scontext=system_u:system_r:container_t:s0:c525,c641 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus" Since we won't allow container_t to access the host DBUS, I suggest to add a new policy that will prevent the logging of this specific AVC. Version-Release number of selected component (if applicable): 0.8.20-0.20191105094256.6578483.el8 How reproducible: Always Steps to Reproduce: 1. Deploy stuff 2. Search audit.log for dbus denials (might take a moment to actually show up) Actual results: We have (useless) entries Expected results: No "send_msg" entry Additional info:
We can create 'dontaudit' rules but we want to make sure we understand that what causes these denials is always harmless. Could you also include a permissive logs when you have a chance?
Hello! ah, didn't realize those logs were from the CI run in Enforcing - the Permissive are the same though: type=USER_AVC msg=audit(12/16/2019 12:16:34.746:20591) : pid=1247 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=371971 scontext=system_u:system_r:container_t:s0:c171,c376 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus permissive=0 exe=/usr/bin/dbus-daemon sauid=dbus hostname=? addr=? terminal=?' There isn't more info nor more related AVCs. For info, my current osp-16 on rhel-8 deploy generates only those last dbus-related AVCs (at least on Director). Cheers, C.
Sorry, I meant the full log file so that we can see more process information. And permissive would help to determine if there are other related denials hidden after - I don't think comment 2 is in permissive either since "permissive=0" is shown?? Thank you!
Looking at the logs in comment #25 on the upstream bug you mentioned this morning ( https://bugs.launchpad.net/tripleo/+bug/1853652/comments/25 ), it looks like the denials occur around some of the healthchecks commands... Which reminds me that contrary to the bug description, in some cases containers do need to access dbus, like in e.g. bug 1738134. Could those denials be causing problems on the monitoring side?
Hello Julie, Actually, we shouldn't allow container_t to access the host dbus - the solution provided for bug 1738134 isn't great, and should be reworked in order to avoid the calls to journalctl|systemd from within a container (work in progress, check https://review.opendev.org/#/q/topic:healthcheck/SyslogIdentifier ). That said, not logging the send_msg might lead to some other issues, since it would mask that a container is doing bad things… On the other hand, since we should be able to remove the policy allowing the container to connect to dbus, we shouldn't see those "send_msg" anymore, right? And since the changes are meant to NOT use journalctl|systemd, it dbus shouldn't be involved, soooo.... we should be clean? WDYT? Cheers, C.
I agree on finding another fix for that other bug. I don't fully understand what causes the send_msg, but it sounds reasonable to leave it aside until the new solution for monitoring is ready and we can confirm they are not showing. Should we close this bug for now, since we don't want the dontaudit at this point?
Closing as "WONTFIX" since we actually won't (need to) fix it now. Also, the validation I'm working on[1] allows to add a kind of skip list, so we can even ignore them in this case. [1] https://review.opendev.org/698006