Description of problem: type=USER_AVC msg=audit(1533273328.656:860): pid=1225 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.systemd1.Manager member=LookupDynamicUserByName dest=org.freedesktop.systemd1 spid=1424 tpid=1 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1533273328.660:861): pid=1225 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=error error_name=org.freedesktop.systemd1.NoSuchDynamicUser dest=:1.47305 spid=1 tpid=6020 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' Version-Release number of selected component (if applicable): selinux-policy-3.14.1-37.fc28.noarch I guess this is sssd trying to tell systemd something.
(In reply to Orion Poplawski from comment #0) > Description of problem: > > type=USER_AVC msg=audit(1533273328.656:860): pid=1225 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.systemd1.Manager member=LookupDynamicUserByName > dest=org.freedesktop.systemd1 spid=1424 tpid=1 > scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:init_t:s0 > tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? > addr=? terminal=?' > type=USER_AVC msg=audit(1533273328.660:861): pid=1225 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=error > error_name=org.freedesktop.systemd1.NoSuchDynamicUser dest=:1.47305 spid=1 > tpid=6020 scontext=system_u:system_r:init_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=dbus permissive=0 > exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' > > > Version-Release number of selected component (if applicable): > selinux-policy-3.14.1-37.fc28.noarch > > I guess this is sssd trying to tell systemd something. I do not think that should be allowed by default. sssd should not have a reason to play with systemd dynamic users in 99% cases. Does it cause some failures in sssd? Could you provide steps to reproduce?
I'm seeing the LookupDynamicUserByName all the time. Not seeing any errors associated with it in the sssd logs. It seems lookups of non-existent users/groups triggers it.
I also see: type=USER_AVC msg=audit(1534200386.118:506): pid=1253 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.systemd1.Manager member=LookupDynamicUserByName dest=org.freedesktop.systemd1 spid=12325 tpid=1 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' coming from sshd. The sssd_t messages seem to be originating from sssd_nss.
I suspect this is coming in "automatically" via /usr/lib64/libnss_systemd.so.2
# grep system /etc/nsswitch.conf group: sss files systemd
(In reply to Orion Poplawski from comment #4) > I suspect this is coming in "automatically" via > /usr/lib64/libnss_systemd.so.2 (In reply to Orion Poplawski from comment #5) > # grep system /etc/nsswitch.conf > group: sss files systemd But I wonder which users is problematic. There is not any reason why sssd whould not return valid user for sshd. And it seems that such user is neither in files. Anyway, I do not think it should be allowed in general.
Why not? Isn't anything that uses nss to lookup users sometimes going to make that call (if it gets to that level)? Why shouldn't anything be able to lookup systemd dynamic users?
(In reply to Orion Poplawski from comment #7) > Why not? Isn't anything that uses nss to lookup users sometimes going to > make that call (if it gets to that level)? Why shouldn't anything be able > to lookup systemd dynamic users? There is not any reason why sssd should query for dynamic users. I can see a reany why there is and avc from sssh_t because it all options from nsswitch. But I cannot see any reason why sssd itself should not find requested data in own database or in files. Allow as much as possible when I see *AVC is not ideal way how to make aplication more secure. There need to be a valid use-case. And quite often it can be fixed in application itself. So please provide more info and use-case which is broken. Otherwise it should not be audited by default.
Adding jhrozek for sssd perspective.
I think the call is indeed caused by libnss_systemd. And the only way I can think about SSSD calling any other NSS module is when sssd calls getpwnam or getpwnam_r. We do this on a couple of places in SSSD, but if Orion says he sees the AVC when a non-existing user is looked up, then chances are that this is the negative cache at play. In the negative cache, we have the following logic: - a user lookup request arrives to SSSD - the user is looked up through SSSD's providers - if the user is not found, sssd calls getpwnam() -- if getpwnam does not return anything, then the user does not exist anywhere and the usual negative cache timeout applies -- if getpwnam does return something, then a much longer negative timeout applies In short, I think there is a valid reason why sssd_nss would be calling getpwnam()
selinux-policy-3.14.1-42.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2d1b09d217
selinux-policy-3.14.1-42.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2d1b09d217
selinux-policy-3.14.1-42.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.