BUG: USER_AVC record on SELinux policy reload malformed

[stevegrubb]

When you run load_policy, you get this in the logs:

type=USER_AVC msg=audit(1485430158.330:324): pid=833 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

There's a lot of dangling text (avc: received policyload notice (seqno=2)). Two possible solutions: 1) send user_mac_policy_load event with no additional text, or 2) change dangling text to op=cleared-cache.

[pcmoore]

@stevegrubb and I just discussed this a bit offline; I'm not sure it makes sense to convert this to a USER_MAC_POLICY_LOAD record (this is a userspace AVC invalidation event due to the kernel loading a new SELinux policy), but I agree that we could/should be doing a better job with the record's "msg" formatting.

[msekletar]

I noticed another related issue with this message. One might argue that message should appear only once for each policy reload. However, this is not the case.

[root@f28 ~]# load_policy && systemctl status >/dev/null # by calling status I force systemd to make access check against the policy
[root@f28 ~]# ausearch -ts recent -m user_avc

time->Tue Sep 11 12:14:30 2018
type=USER_AVC msg=audit(1536668070.055:678): pid=469 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  received policyload notice (seqno=3)  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Tue Sep 11 12:14:30 2018
type=USER_AVC msg=audit(1536668070.070:680): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=3)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Notice that one message is generated by dbus-daemon while other is from systemd. I assume that on a system with X11 I'd probably see third such message from xorg. The problem is that each application that uses libselinux, and has overridden default logging callback with one that forwards libselinux messages to auditd, will produce one of those messages as soon as the application calls selinux_check_access().

I think it should be the kernel who generates the message. User-space should only take notice of the change and silently (by default) invalidate its AVC (or do whatever else is necessary to make sure that followup checks against policy don't generate incorrect results).

[pcmoore]

@msekletar I believe the issue with the multiple notices in this case is due to both dbus and systemd acting as userspace object managers and thus they both receive AVC policy load notices so they can take whatever actions are necessary.

The issue isn't so much with the audit subsystem in the kernel, or auditd, but rather how these userspace object managers use libselinux. I would suggest brining this up on the SELinux developers list so it can be discussed.

• https://www.nsa.gov/what-we-do/research/selinux/mailing-list.shtml

[msekletar]

• https://www.nsa.gov/what-we-do/research/selinux/mailing-list.shtml

I will start a discussion there. Thank you!

[rgbriggs]

@stevegrubb and I just discussed this a bit offline; I'm not sure it makes sense to convert this to a USER_MAC_POLICY_LOAD record (this is a userspace AVC invalidation event due to the kernel loading a new SELinux policy), but I agree that we could/should be doing a better job with the record's "msg" formatting.

Since this is the format of a user-generated message this doesn't appear to be a kernel issue. Can we close this here and open in in audit-userspace if that is even appropriate?

[pcmoore]

Since this is the format of a user-generated message this doesn't appear to be a kernel issue. Can we close this here and open in in audit-userspace if that is even appropriate?

I think that's the right decision. Although honestly, I'm not even 100% certain it really belongs in audit-userspace either. This really looks like an issue with the individual SELinux userspace object managers, or the SELinux userspace libraries; it all depends on where the message is being generated (application or library).