Description of problem: Failing to login via sssd. Looking into the sssd debug logs, there were permission related errors to sssd/krb5 cache. Set SELinux to permissive and the login was successful. I currently do not have the debug logs but captured the SELinux issue. Version-Release number of selected component (if applicable): sssd-1-16.0-5.fc27.x86_64 How reproducible: With SELinux enabled Steps to Reproduce: 1. ssh user@localhost Actual results: Permission denied Expected results: Login successful Additional info: Jan 23 18:13:19 akuh setroubleshoot[11404]: SELinux is preventing krb5_child from write access on the sock_file .heim_org.h5l.kcm-socket. For complete SELinux messages run: sealert -l cd2aea11-6ddd-41ec-a6a1-938 b48d16e3e Jan 23 18:13:19 akuh python3[11404]: SELinux is preventing krb5_child from write access on the sock_file .heim_org.h5l.kcm-socket.#012#012***** Plugin catchall (100. confidence) suggests ********************* *****#012#012If you believe that krb5_child should be allowed write access on the .heim_org.h5l.kcm-socket sock_file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'krb5_child' --raw | audit2allow -M my-krb5child#012# semodule -X 300 -i my-krb5child.pp#012
Could you provide an output of "sealert -l cd2aea11-6ddd-41ec-a6a1-938b48d16e3e" ? Or at least AVCs? ls -lZ /var/run/.heim_org.h5l.kcm-socket would be helpful as well
I was not able to replicate the issue setting SELinux back to enforcing. The logs from the previously failed attempt were not on the system. This was a brand new install/configuration and failed for the first login attempt.
This issue still occurs when using the sssd-kcm socket on Fedora 27. The context on the socket file is set as follows. [root@dev00-f27 ~]# ls -lZ /var/run/.heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:var_run_t:s0 0 Feb 9 10:28 /var/run/.heim_org.h5l.kcm-socket Audit logs show the following error. [root@mdct-dev27-f27 ~]# ausearch -c 'krb5_child' --raw type=AVC msg=audit(1518126803.087:481): avc: denied { write } for pid=12671 comm="krb5_child" name=".heim_org.h5l.kcm-socket" dev="tmpfs" ino=65617 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 SELinux also prevents the socket file from being relabeled. type=AVC msg=audit(1518192957.380:626): avc: denied { relabelto } for pid=25329 comm="chcon" name=".heim_org.h5l.kcm-socket" dev="tmpfs" ino=614135 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sssd_t:s0 tclass=sock_file permissive=0
Some additional testing shows that restorecon is able to reset the label to the proper context. [root@dev00-f27 run]# restorecon -Fv .heim_org.h5l.kcm-socket Relabeled /run/.heim_org.h5l.kcm-socket from system_u:object_r:var_run_t:s0 to system_u:object_r:sssd_var_run_t:s0 Setting a type transition also causes the socket file to be created properly as shown below. [root@dev00 ~]# echo '(typetransition sssd_t var_run_t sock_file sssd_var_run_t)' > sssd_sock_transition.cil && semodule -i sssd_sock_transition.cil [root@dev00 run]# systemctl start sssd-kcm.socket sssd-kcm.service [root@dev00 run]# ls -lZ .heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 9 11:35 .heim_org.h5l.kcm-socket Would it be possible to update the sssd-kcm package to include this setting by default? Kerberos authentication will not work on Fedora 27 nodes without this policy in place.
(In reply to Michael Watters from comment #9) > SELinux also prevents the socket file from being relabeled. > > type=AVC msg=audit(1518192957.380:626): avc: denied { relabelto } for > pid=25329 comm="chcon" name=".heim_org.h5l.kcm-socket" dev="tmpfs" > ino=614135 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:sssd_t:s0 tclass=sock_file permissive=0 I think that is the main issue. That relabel is not allowed. But I wonder which process tried to do that action because source context unconfined_t is really unexpected. The audit message says that command was "chcon". Was it executed from such process? or from command line. Do you know how to reproduce creating file with var_run_t; because systemd created file with right SELinux file context for me sh# systemctl stop sssd-kcm.service sssd-kcm.socket sh# rm -f /var/run/.heim_org.h5l.kcm-socket sh# systemctl start sssd-kcm.socket sh# ls -lZ /var/run/.heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 9 18:26 /var/run/.heim_org.h5l.kcm-socket BTW your proposal seems right to me. I will consult that with SELinux maintainers.
> The audit message says that command was "chcon". Was it executed from such > process? or from command line. I was attempting to chcon the socket from the command line. You can disregard this error. restorecon does restore the correct context however it shouldn't be necessary to run this every time the service is restarted. > Do you know how to reproduce creating file with var_run_t; because systemd > created file with right SELinux file context for me > > sh# systemctl stop sssd-kcm.service sssd-kcm.socket > sh# rm -f /var/run/.heim_org.h5l.kcm-socket > > sh# systemctl start sssd-kcm.socket > sh# ls -lZ /var/run/.heim_org.h5l.kcm-socket > srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 9 18:26 > /var/run/.heim_org.h5l.kcm-socket > > BTW your proposal seems right to me. I will consult that with SELinux > maintainers. Unfortunately I have not been able to reproduce the issue consistently. A brand new Fedora 27 install does have the proper security context as shown below. I am not certain what is causing the socket file to change. [root@dev00-f27 run]# ls -lZ .heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 12 08:22 .heim_org.h5l.kcm-socket
(In reply to Michael Watters from comment #10) > Some additional testing shows that restorecon is able to reset the label to > the proper context. > > [root@dev00-f27 run]# restorecon -Fv .heim_org.h5l.kcm-socket > Relabeled /run/.heim_org.h5l.kcm-socket from system_u:object_r:var_run_t:s0 > to system_u:object_r:sssd_var_run_t:s0 > > Setting a type transition also causes the socket file to be created properly > as shown below. > > [root@dev00 ~]# echo '(typetransition sssd_t var_run_t sock_file > sssd_var_run_t)' > sssd_sock_transition.cil && semodule -i > sssd_sock_transition.cil > FYI that transition is already allowed in current selinux-policy. So that workaround could not help you. sh# sesearch -T -s sssd_t -c sock_file type_transition sssd_t tmp_t:sock_file user_tmp_t; type_transition sssd_t tmpfs_t:sock_file user_tmp_t; type_transition sssd_t var_run_t:sock_file sssd_var_run_t; > [root@dev00 run]# systemctl start sssd-kcm.socket sssd-kcm.service > > [root@dev00 run]# ls -lZ .heim_org.h5l.kcm-socket > srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 9 11:35 > .heim_org.h5l.kcm-socket > restorecon or systemctl start sssd-kcm.service usually helped me. sh-4.4# systemctl stop sssd-kcm.{service,socket} sh-4.4# rm -f /var/run/.heim_org.h5l.kcm-socket sh-4.4# nc -l --unix /var/run/.heim_org.h5l.kcm-socket ^C sh-4.4# ls -lZ /var/run/.heim_org.h5l.kcm-socket srwxr-xr-x. 1 root root unconfined_u:object_r:var_run_t:s0 0 Feb 12 15:33 /var/run/.heim_org.h5l.kcm-socket sh-4.4# systemctl start sssd-kcm.service sh-4.4# ls -lZ /var/run/.heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 12 15:33 /var/run/.heim_org.h5l.kcm-socket or another example with starting only socket sh-4.4# systemctl stop sssd-kcm.{service,socket} sh-4.4# rm -f /var/run/.heim_org.h5l.kcm-socket sh-4.4# nc -l --unix /var/run/.heim_org.h5l.kcm-socket ^C sh-4.4# ls -lZ /var/run/.heim_org.h5l.kcm-socket srwxr-xr-x. 1 root root unconfined_u:object_r:var_run_t:s0 0 Feb 12 15:34 /var/run/.heim_org.h5l.kcm-socket sh-4.4# systemctl start sssd-kcm.socket sh-4.4# ls -lZ /var/run/.heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:sssd_var_run_t:s0 0 Feb 12 15:34 /var/run/.heim_org.h5l.kcm-socket > Would it be possible to update the sssd-kcm package to include this setting > by default? Kerberos authentication will not work on Fedora 27 nodes > without this policy in place. sssd-kcm needn't be updated because selinux-maintainer found some issue in selinux-policy. It's already fixed in upstream f26+ and will get to fedora with next update. But It would be good to find out which process creates kcm socket as unconfined. Because it should properly work with systemd + socket activation. If you find out reproducer please let us know.
Hello, I by chance happened to be having this exact issue, and was wondering if you still need someone to reproduce it. I have the system in permissive mode at the moment (I _did_ actually need to log in), but I can run whatever you need. I've also stopped dnf-automatic-install, so I shouldn't (as far as packages) have any changes since the issue. Here's some info: Feb 13 19:21:11 ws01-fed.int.trae32566.org python3[13211]: SELinux is preventing krb5_child from write access on the sock_file .heim_org.h5l.kcm-socket. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that krb5_child should be allowed write access on the .heim_org.h5l.kcm-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 'krb5_child' --raw | audit2allow -M my-krb5child # semodule -X 300 -i my-krb5child.pp Feb 13 19:21:11 ws01-fed.int.trae32566.org setroubleshoot[13211]: SELinux is preventing krb5_child from write access on the sock_file .heim_org.h5l.kcm-socket. For complete SELinux messages run: sealert -l 5fe4e887-1ad5-4fe9-91b3-b4c299887553 [root@ws01-fed ~]# grep denied /var/log/audit/audit.log | tail -1 | audit2why type=AVC msg=audit(1518571267.405:6463): avc: denied { write } for pid=13174 comm="krb5_child" name=".heim_org.h5l.kcm-socket" dev="tmpfs" ino=67181515 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. [root@ws01-fed ~]# ls -lZ /var/run/.heim_org.h5l.kcm-socket srw-rw-rw-. 1 root root system_u:object_r:var_run_t:s0 0 Feb 12 21:40 /var/run/.heim_org.h5l.kcm-socket [root@ws01-fed ~]# sealert -l 5fe4e887-1ad5-4fe9-91b3-b4c299887553 Error query_alerts error (1003): id (5fe4e887-1ad5-4fe9-91b3-b4c299887553) not found I'm not quite sure why sealert doesn't even see the error, but that might be a red herring. Also, I'm on Freenode in #fedora as trae32566, or (depending on time) trae32566[w], so feel free to hit me up there if you need something in particular. Thanks, Trae S.
(In reply to Trae Santiago from comment #14) > Hello, > > I by chance happened to be having this exact issue, and was wondering if you > still need someone to reproduce it. I have the system in permissive mode at > the moment (I _did_ actually need to log in), but I can run whatever you > need. I've also stopped dnf-automatic-install, so I shouldn't (as far as > packages) have any changes since the issue. Here's some info: > > Feb 13 19:21:11 ws01-fed.int.trae32566.org python3[13211]: SELinux is > preventing krb5_child from write access on the sock_file > .heim_org.h5l.kcm-socket. > The current situation is not very interesting. I can simulate it as well. But we would need to know previous steps which occurred before the AVC. In another words which process created the /var/run/.heim_org.h5l.kcm-socket with wrong SELinux file context. BTW workaround is quite simple: either call restorecon /var/run/.heim_org.h5l.kcm-socket or reboot machine.
selinux-policy-3.13.1-283.26.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a9711c96b2
selinux-policy-3.13.1-283.26.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-2018-a9711c96b2
selinux-policy-3.13.1-283.26.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.