Hide Forgot
Description of problem: I am using sssd to provide authorization and authentication services. The targeted SELinux policy seems to block my ability to login using GDM when GDM is configured to use sssd. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.9.7-25.fc14.noarch sssd-1.5.0-2.fc14.x86_64 How reproducible: Every time Steps to Reproduce: 1. Boot with SELinux enforcing the targeted policy 2. Configure sssd to talk to LDAP and Kerberos 3. Configure host to talk to sssd (PAM and NSS) Actual results: Login fails. type=AVC msg=audit(1296501633.935:26): avc: denied { getattr } for pid=1254 comm="sssd_be" path="/tmp/krb5cc_1101_wOIzcC" dev=dm-1 ino=23458 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file type=SYSCALL msg=audit(1296501633.935:26): arch=c000003e syscall=6 success=no exit=-13 a0=1806875 a1=7fff96c7b260 a2=7fff96c7b260 a3=7f5d25ebb1e0 items=0 ppid=1248 pid=1254 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sssd_be" exe="/usr/libexec/sssd/sssd_be" subj=system_u:system_r:sssd_t:s0 key=(null) type=USER_AUTH msg=audit(1296501635.996:27): user pid=1818 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="mike" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1296501635.998:28): user pid=1818 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1101: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=failed' Expected results: Login succeeds if I turn off SELinux. Additional info:
> Expected results: > Login succeeds if I turn off SELinux. You mean you disabled SELinux or just switched to permissive mode? What is the SELinux context you get when you login? # id -Z
sssd is trying to create kerberos tickets in /tmp, for the user. This looks like the /tmp/krb5cc_11* was labeled incorrectly. It should be labeled user_tmp_t. If you delete the kerbeross credential cache, does sssd work correctly?
I deleted /tmp/krb5cc*. After I did this, I was able to login. The Kerberos library created a new credential file, /tmp/krb5cc_1101_ecK3Mk, but its context was system_u:object_r:user_tmp_t:s0. So, I think this issue was a result of a filesystem relabel that happened after rebooting. Shouldn't the label of this file be more restrictive anyway?
restorecon of this file should not change its label to anything but user_tmp_t. Now if you were in permissive mode and created this file it could have the wrong label. Just watch for it getting the wrong label again, then we can try to figure out how it is getting the wrong label.