Bug 767363

Summary: sssd should be allowed to manipulate kerberos's ticket.
Product: [Fedora] Fedora Reporter: Forlot Romain <rforlot>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-15 17:09:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Forlot Romain 2011-12-13 21:36:46 UTC
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

Comment 1 Daniel Walsh 2011-12-13 21:44:52 UTC
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?

Comment 2 Forlot Romain 2011-12-14 07:35:59 UTC
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 ?

Comment 3 Daniel Walsh 2011-12-14 14:39:27 UTC
Because the domain that created them would have been denied in enforcing mode.  Do you know which process created the files?

Comment 4 Forlot Romain 2011-12-14 20:41:17 UTC
Not sure. either by sssd or by kinit

Comment 5 Daniel Walsh 2011-12-14 20:52:53 UTC
Well if you delete them can you recreate them with tmp_t as a context not, user_tmp_t?

Comment 6 Forlot Romain 2011-12-15 11:40:49 UTC
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.

Comment 7 Forlot Romain 2011-12-15 12:10:22 UTC
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.

Comment 8 Daniel Walsh 2011-12-15 17:09:14 UTC
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.