Richard Haines <richard_c_haines@xxxxxxxxxxxxxx> writes: > On Wed, 2020-08-26 at 15:15 -0400, Chris PeBenito wrote: >> On 8/26/20 3:07 PM, Dominick Grift wrote: >>> Chris PeBenito <chpebeni@xxxxxxxxxxxxxxxxxxx> writes: >>> > >>>> On 8/26/20 10:46 AM, Stephen Smalley wrote: >>>>> On Wed, Aug 26, 2020 at 10:35 AM Chris PeBenito >>>>> <chpebeni@xxxxxxxxxxxxxxxxxxx> wrote: >>>>>> On 8/26/20 9:25 AM, Chris PeBenito wrote: >>>>>>> I was looking into this dbus-broker audit message, which >>>>>>> has the wrong audit type: >>>>>>> > >>>>>>> audit[422]: USER_AVC pid=422 uid=999 auid=4294967295 >>>>>>> ses=4294967295 >>>>>>> subj=system_u:system_r:system_dbusd_t msg='avc: received >>>>>>> policyload notice >>>>>>> (seqno=2) >>>>>>> > >>>>>>> This is due to dbus-broker setting their avc log callback >>>>>>> to send USER_AVC audit >>>>>>> messages for everything that comes to the libselinux log >>>>>>> callback. I think the >>>>>>> right thing to do there is to change it to emit >>>>>>> USER_SELINUX_ERR audit messages >>>>>>> if the log message is SELINUX_ERROR, otherwise log the >>>>>>> message using their >>>>>>> regular method (stderr I think). >>>>>>> > >>>>>>> But the question became, why is the userspace AVC not >>>>>>> simply emitting its own >>>>>>> USER_MAC_POLICY_LOAD audit message instead of sending a >>>>>>> message to the log >>>>>>> callback? >>>>>> > >>>>>> Ok, I missed that there is a SELINUX_AVC log type and that's >>>>>> how the userspace >>>>>> denial messages are sent out. How about adding >>>>>> SELINUX_POLICYLOAD and >>>>>> SELINUX_ENFORCE log types so that callers can emit >>>>>> appropriate audit messages? >>>>> Do we need two different new types or just one? Otherwise, I >>>>> don't >>>>> have a problem with adding new ones as long as it doesn't break >>>>> existing applications. >>>> > >>>> Regarding the risk of breaking existing applications, I did some >>>> checking on some userspace AVC users and what they do in their >>>> log >>>> callback: >>>> > >>>> * systemd only audits SELINUX_AVC and SELINUX_ERROR messages and >>>> ignores others(as Petr noted) >>>> * xorg-server audits SELINUX_AVC correctly but audits >>>> SELINUX_INFO as >>>> USER_MAC_POLICY_LOAD and everything else it ignores the type >>>> and >>>> audits as AUDIT_USER_SELINUX_ERR >>>> * dbus-broker ignores type and audits everything as USER_AVC >>>> * dbus-service ignores type and audits everything as USER AVC >>>> * pam: pam_rootok ignores type and audits everything as USER_AVC >>>> * sepgsql custom AVC implementation (this was news to me) >>>> * shadow-utils only audits SELINUX_AVC and SELINUX_ERROR messages >>>> and >>>> others go to syslog >>>> * cronie: no callback set >>>> > >>>> That's all the ones I could think of. Which ones am I missing? >>> > >>> Probably libreswan, AFAIK that one might also still be using >>> avc_has_perm() instead of selinux_check_access(). >> > >> You're correct, it is still use avc_has_perm(). There is no log >> callback set here. >> > > ipsec-tools (racoon) is another. I did patches for this and LibreSwan > a few years ago, they never went far: > > ipsec-tools: > https://marc.info/?l=ipsec-tools-devel&m=149441917501329&w=2 > LibreSwan: > https://lists.libreswan.org/pipermail/swan-dev/2017-May/001860.html > > I visited #swan and reminded the maintainers of the libreswan patch, they are going to address your patch. ipsec-tools is dead and have CVE's and so not sure if there is any point to that. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
