On some laptops that are connected to freeipa and have been upgraded to F26, logins stopped working due to an selinux issue. It doesn't happen on all of them and a clean install does fix it, but it would be nice if that wasn't necessary. Given that the file is on a tmpfs, I don't think a relabel would fix anything. The full error message is: SELinux is preventing selinux_child from write access on the sock_file system_bus_socket. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that selinux_child should be allowed write access on the system_bus_socket sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'selinux_child' --raw | audit2allow -M my-selinuxchild # semodule -X 300 -i my-selinuxchild.pp Additional Information: Source Context system_u:system_r:sssd_selinux_manager_t:s0 Target Context system_u:object_r:system_dbusd_var_run_t:s0 Target Objects system_bus_socket [ sock_file ] Source selinux_child Source Path selinux_child Port <Unknown> Host hostname.domain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-260.6.fc26.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hostname.domain Platform Linux hostname.domain 4.12.9-300.fc26.x86_64 #1 SMP Fri Aug 25 13:09:43 UTC 2017 x86_64 x86_64 Alert Count 3 First Seen 2017-09-04 16:44:40 PDT Last Seen 2017-09-04 18:04:16 PDT Local ID 21fda78f-20ac-4e98-8598-285ad3e0eb4c Raw Audit Messages type=AVC msg=audit(1504573456.834:252): avc: denied { write } for pid=3888 comm="selinux_child" name="system_bus_socket" dev="tmpfs" ino=17290 scontext=system_u:system_r:sssd_selinux_manager_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Hash: selinux_child,sssd_selinux_manager_t,system_dbusd_var_run_t,sock_file,write
I'm not aware of any code changes to the selinux_child process so I wonder if the selinux-policy maintainer is aware of any change to the policy that could cause this?
Could you provide AVCs in permissive mode?
I think that's still the only one, but I'll check.
Btw, I did put one of the laptops in permissive mode and logins work. That's the only one I haven't reinstalled so far, so I'll check it in the morning.
BTW It is allowed in f27 [root@f26 ~]# sesearch -rs -s "sssd_.*" -t system_dbusd_var_run_t -c sock_file -p write --allow allow sssd_t system_dbusd_var_run_t:sock_file { append getattr open write }; [root@f27 ~]# sesearch -rs -s "sssd_.*" -t system_dbusd_var_run_t -c sock_file -p write --allow allow domain pidfile:sock_file { append getattr open write }; allow sssd_t system_dbusd_var_run_t:sock_file { append getattr open write };
A couple of the laptops have resolved this issue after rebooting once or twice, but I have one that still isn't working. Here are possibly relevant audit entries with permissive mode: type=AVC msg=audit(1504711388.168:268): avc: denied { write } for pid=2586 comm="selinux_child" name="system_bus_socket" dev="tmpfs" ino= 22551 scontext=system_u:system_r:sssd_selinux_manager_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive= 1 type=USER_AVC msg=audit(1504711388.171:269): pid=666 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1 023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=2586 scontext=system_u:system_r:sssd_selinux_manager_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus exe="/usr/bin/dbu s-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1504711388.175:270): pid=666 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1 023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.systemd1.Manager member=LookupDynamicUserByName dest=o rg.freedesktop.systemd1 spid=2586 tpid=1 scontext=system_u:system_r:sssd_selinux_manager_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=db us exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1504711388.176:271): pid=666 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1 023 msg='avc: denied { send_msg } for msgtype=error error_name=org.freedesktop.systemd1.NoSuchDynamicUser dest=:1.68 spid=1 tpid=2586 scon text=system_u:system_r:init_t:s0 tcontext=system_u:system_r:sssd_selinux_manager_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostn ame=? addr=? terminal=?' type=USER_AVC msg=audit(1504711390.938:272): pid=666 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1 023 msg='avc: received policyload notice (seqno=2) exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
IMHO that issue in selinux-policy. Lukas, Could you confirm? See also 1488327#c5
I tried hard but I was not able to find which commit in rawhide branch fixed that AVC. In another words; I was not able to find which macro included the second allow rule in following output on f27 [root@f27 ~]# sesearch -rs -s "sssd_.*" -t system_dbusd_var_run_t -c sock_file -p write --allow allow domain pidfile:sock_file { append getattr open write }; allow sssd_t system_dbusd_var_run_t:sock_file { append getattr open write };
libsemanage can use getpwnam_r and AVC is caused by communication libnss_systemd with systemd dbus grep passwd /etc/nsswitch.conf #passwd: db files nisplus nis passwd: sss files systemd I was able to fix it in sssd in on of testing systems. Samuel, if you still can reproduce I can provide a testing package for you.
I think there's still at least one laptop with this problem. If so, I'll try it.
Here you are https://koji.fedoraproject.org/koji/taskinfo?taskID=21792782
sssd-1.15.3-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c964b58aca
sssd-1.15.3-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4a479d6a57
sssd-1.15.3-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-43b6d5bc6b
sssd-1.15.3-4.fc27 has been pushed to the Fedora 27 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-2017-c964b58aca
sssd-1.15.3-4.fc26 has been pushed to the Fedora 26 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-2017-4a479d6a57
Did you have a change to test packages from updates-tesing?
I have installed them on a computer that was showing the problem. I'll get someone to test it on Monday. Unfortunately, it will be difficult to tell if it's fixed because of the packages or because it's just not happening any more. That one laptop that was still doing this is no longer doing it. But I'll try to make sure this computer doesn't get rebooted.
Someone finally tested it and it works, so I assume this fixed it.
sssd-1.15.3-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.15.3-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.