Hide Forgot
Description of problem: With SElinux enforcing, It's impossible to connect an user with kerberos authentification because sssd it is not allowed to manipulate kerberos ticket in /tmp Version-Release number of selected component (if applicable): How reproducible: Get a kerberos authentification working and use sssd to use it. Then try to connect an user. Steps to Reproduce: 1. configure sssd to use kerberos authentification. 2. try to connect to a normal user Actual results: Authentification return an error and doesn't allow to connect at the system. By ssh we have this error : "Password authentification failed. Please verify the username and password are correct" Expected results: With SElinux permissive, log is OK. Additional info: AVC denial for login sequence with SElinux enforcing: Dec 13 22:33:00 gilgamesh dbus[1445]: avc: received setenforce notice (enforcing=1) Dec 13 22:33:00 gilgamesh dbus-daemon[1445]: dbus[1445]: avc: received setenforce notice (enforcing=1) Dec 13 22:33:00 gilgamesh dbus-daemon[1445]: dbus[1445]: [system] Reloaded configuration Dec 13 22:33:00 gilgamesh dbus[1445]: [system] Reloaded configuration Dec 13 22:33:12 gilgamesh kernel: [ 7031.171326] type=1400 audit(1323811992.387:867): avc: denied { getattr } for pid=1828 comm="sssd_be" path="/tmp/krb5cc_1010_9gXDRn" dev=dm-11 ino=1799405 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file AVC denial for login sequence with SElinux permissive : Dec 13 22:34:19 gilgamesh dbus[1445]: avc: received setenforce notice (enforcing=0) Dec 13 22:34:19 gilgamesh dbus-daemon[1445]: dbus[1445]: avc: received setenforce notice (enforcing=0) Dec 13 22:34:21 gilgamesh kernel: [ 7100.273491] type=1400 audit(1323812061.490:869): avc: denied { getattr } for pid=1828 comm="sssd_be" path="/tmp/krb5cc_1010_9gXDRn" dev=dm-11 ino=1799405 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file Dec 13 22:34:21 gilgamesh kernel: [ 7100.290436] type=1400 audit(1323812061.507:870): avc: denied { read } for pid=1828 comm="sssd_be" name="krb5cc_1010_9gXDRn" dev=dm-11 ino=1799405 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file Dec 13 22:34:21 gilgamesh kernel: [ 7100.290452] type=1400 audit(1323812061.507:871): avc: denied { open } for pid=1828 comm="sssd_be" name="krb5cc_1010_9gXDRn" dev=dm-11 ino=1799405 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file Dec 13 22:34:21 gilgamesh kernel: [ 7100.290470] type=1400 audit(1323812061.507:872): avc: denied { lock } for pid=1828 comm="sssd_be" path="/tmp/krb5cc_1010_9gXDRn" dev=dm-11 ino=1799405 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file Dec 13 22:34:21 gilgamesh kernel: [ 7100.568736] type=1400 audit(1323812061.785:873): avc: denied { unlink } for pid=15221 comm="krb5_child" name="krb5cc_1010_9gXDRn" dev=dm-11 ino=1799405 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file
How did these files get created in the first place. Please remove them and try again. Krb5cc_* files should be labeled user_tmp_t not tmp_t. The only way I can think of these files being created with this label would be if they were created in permissive mode or you changed the context of them with chcon. sesearch -A -s sssd_t -t user_tmp_t -c file -C Found 2 semantic av rules: allow sssd_t user_tmp_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ; If they were created correctly with the right label, sssd would be allowed to manage them. Any idea how they got that label?
There were created in permissive mode. I don't knew that the label file were differents between permissive and enforcing. Why label isn't the same selinux mode ?
Because the domain that created them would have been denied in enforcing mode. Do you know which process created the files?
Not sure. either by sssd or by kinit
Well if you delete them can you recreate them with tmp_t as a context not, user_tmp_t?
Ok, after some tests, I found how to reproduce the mislabeling. 1. Boot SElinux disabled 2. Log in or kinit a principal 3. Ticket cache file haven't a label ( file with an "?" ) 4. Set up enforcing selinux 5. reboot 6. Ticket cache file have parent directory label system_u:object_r:tmp_t:s0.
Yes we can not handle labeling on /tmp since, we have no idea what kind of files would be there. I always use a tmpfs for /tmp so any cruft left there gets cleaned up on reboot.