Bug 509223

Summary: SELinux is preventing sshd (sshd_t) "getattr" to /var/tmp/host_0 (xdm_tmp_t)
Product: [Fedora] Fedora Reporter: Tim Scofield <twscofi>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: dwalsh, mgrepl, nalin
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-21 20:52:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tim Scofield 2009-07-01 19:54:16 UTC
Description of problem:
Cannot login via ssh 
SELinux is preventing sshd (sshd_t) "getattr" to /var/tmp/host_0 (xdm_tmp_t).


Summary:

SELinux is preventing sshd (sshd_t) "getattr" to /var/tmp/host_0 (xdm_tmp_t).

Detailed Description:

SELinux denied access requested by sshd. /var/tmp/host_0 may be a mislabeled.
/var/tmp/host_0 default SELinux type is krb5_host_rcache_t, but its current type
is xdm_tmp_t. Changing this file back to the default type, may fix your problem.

File contexts can be assigned to a file in the following ways.

  * Files created in a directory receive the file context of the parent
    directory by default.
  * The SELinux policy might override the default label inherited from the
    parent directory by specifying a process running in context A which creates
    a file in a directory labeled B will instead create the file with label C.
    An example of this would be the dhcp client running with the dhclient_t type
    and creates a file in the directory /etc. This file would normally receive
    the etc_t type due to parental inheritance but instead the file is labeled
    with the net_conf_t type because the SELinux policy specifies this.
  * Users can change the file context on a file using tools such as chcon, or
    restorecon.

This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.

However, this might also indicate a bug in SELinux because the file should not
have been labeled with this type.

If you believe this is a bug, please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

You can restore the default system context to this file by executing the
restorecon command. restorecon '/var/tmp/host_0', if this file is a directory,
you can recursively restore using restorecon -R '/var/tmp/host_0'.

Fix Command:

restorecon '/var/tmp/host_0'

Additional Information:

Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:xdm_tmp_t:s0
Target Objects                /var/tmp/host_0 [ file ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          <Unknown>
Host                          hostname-deleted
Source RPM Packages           openssh-server-5.2p1-2.fc11
Target RPM Packages
Policy RPM                    selinux-policy-3.6.12-53.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   restorecon
Host Name                     hostname-deleted
Platform                      Linux hostname-deleted
                              2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16
                              23:23:21 EDT 2009 x86_64 x86_64
Alert Count                   6
First Seen                    Wed 01 Jul 2009 01:11:50 PM MDT
Last Seen                     Wed 01 Jul 2009 01:47:05 PM MDT
Local ID                      944c01d9-4c37-4185-878d-05d7e0bacfb1
Line Numbers

Raw Audit Messages

node=hostname-deleted type=AVC msg=audit(1246477625.330:27549): avc:  denied  { getat
tr } for  pid=21875 comm="sshd" path="/var/tmp/host_0" dev=dm-0 ino=248 scontext=syst
em_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_tmp_t:s0 tclass=fi
le

node=hostname-deleted type=SYSCALL msg=audit(1246477625.330:27549): arch=c000003e sys
call=4 success=no exit=-13 a0=7f401fc1d970 a1=7fff1e899f30 a2=7fff1e899f30 a3=10 item
s=0 ppid=1898 pid=21875 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid
=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:s
ystem_r:sshd_t:s0-s0:c0.c1023 key=(null)

Comment 1 Daniel Walsh 2009-07-01 20:48:17 UTC
restorecon on this should fix.

restorecon /var/tmp/host_0

Strange the kerberos libraries are supposed to prevent this from happening.

Comment 2 Tim Scofield 2009-07-02 16:52:49 UTC
This may be a different bug, but for the moment it's continued here because I'm currently having a problem with SELinux & /var/tmp/host_0 that causes my window manager to restart

I ran restorecon on /var/tmp/host_0 yesterday, and I could ssh into my system.  I also rebooted and tested it again and it worked. 

Now I'm getting the error below accessing host_0 (I did update my system late yesterday and this morning, but I don't think the packages would affect this).

I can still ssh into my system, so the suggested fix worked for ssh, but it seems to have messed up other SElinux policies.

When I try to use login it kills my kde session. Also kerberized logins have stopped working (kinit still works), but I do not see an associated SElinux error in the audit log. 

Summary:

SELinux is preventing the login from using potentially mislabeled files
(host_0).                                                              

Detailed Description:

SELinux has denied login access to potentially mislabeled file(s) (host_0). This
means that SELinux will not allow login to use these files. It is common for    
users to edit files in their home directory or tmp directories and then move    
(mv) them to system directories. The problem is that the files end up with the  
wrong file context which confined applications are not allowed to access.       

Allowing Access:

If you want login to access this files, you need to relabel them using
restorecon -v 'host_0'. You might want to relabel the entire directory using
restorecon -R -v ''.                                                        

Additional Information:

Source Context                system_u:system_r:local_login_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:user_tmp_t:s0           
Target Objects                host_0 [ file ]                               
Source                        login                                         
Source Path                   /bin/login                                    
Port                          <Unknown>                                     
Host                          hostname-deleted                              
Source RPM Packages           util-linux-ng-2.14.2-9.fc11                   
Target RPM Packages                                                         
Policy RPM                    selinux-policy-3.6.12-53.fc11                 
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   home_tmp_bad_labels
Host Name                     hostname-deleted
Platform                      Linux hostname-deleted
                              2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16
                              23:23:21 EDT 2009 x86_64 x86_64
Alert Count                   5
First Seen                    Thu 02 Jul 2009 08:07:26 AM MDT
Last Seen                     Thu 02 Jul 2009 09:35:40 AM MDT
Local ID                      2bcfc859-26ad-42da-9145-232d50112754
Line Numbers

Raw Audit Messages

node=hostname-deleted type=AVC msg=audit(1246548940.465:143): avc:  denied  { read write } for  pid=13330 comm="login" name="host_0" dev=dm-0 ino=26820 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

node=hostname-deleted type=SYSCALL msg=audit(1246548940.465:143): arch=c000003e syscall=2 success=no exit=-13 a0=12d8540 a1=2 a2=180 a3=10 items=0 ppid=1 pid=13330 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty2 ses=4294967295 comm="login" exe="/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)

Comment 3 Tim Scofield 2009-07-02 19:24:37 UTC
Hmm. The display manager crashes are not as repeatable as they first appeared. 

On the other hand, setenforce 0 will allow kdm & login to use kerberos. I still only see the error associated with login.

Comment 4 Tim Scofield 2009-07-06 16:41:20 UTC
Note:  as of https://bugzilla.redhat.com/show_bug.cgi?id=503061#c6 kerberos login with kdm and login worked.

Comment 5 Daniel Walsh 2009-07-06 17:46:59 UTC
Ok I just checked with an updated Fedora system

selinux-policy-3.6.12-57.fc11
krb5-libs-1.6.3-20.fc11

And I can not get this file to be mislabeled.

I used 

sshd, telnetd, krb5-telnetd, xdm, kdm

So the only thing I can think of was these files were created with a previous bug in policy or libraries which mislabeled the file,   If you remove the file, I believe it will get created with the correct context, and if you leave the file labeled as is after a restorecon, you should be all set.  If you can recreate the file with the wrong context using a login program, please reopen this bug.

Comment 6 Tim Scofield 2009-07-06 19:46:19 UTC
Removed /var/tmp/host_0 as suggested (and the rest of the /var/tmp directory contents for good measure)

Kerberos based logins are now working with login, kdm, & ssh. 

rpm -q selinux-policy krb5-libs
selinux-policy-3.6.12-53.fc11.noarch
krb5-libs-1.6.3-20.fc11.x86_64

I have no evidence that the intermittent display manager crashes that started at roughly the same time are related. But the logs do make one suspicious:

Jul  6 11:47:51 host-deleted setroubleshoot: SELinux is preventing the login from using potentially mislabeled files (host_0). For complete SELinux messages. run sealert -l 2bcfc859-26ad-42da-9145-232d50112754
Jul  6 11:47:51 host-deleted kdm[2007]: X server for display :0 terminated unexpectedly

But other messages show the X crashes a few seconds off of the selinux errors, and I (and others) have been having occasional, but non-fatal, X problems with i915_gem. 


Thanks for the helpful suggestions

Comment 7 Daniel Walsh 2009-07-06 20:55:45 UTC
What does

ls -lZ /var/tmp/host_0

Say?

Comment 8 Tim Scofield 2009-07-06 21:44:24 UTC
ls -lZ /var/tmp/host_0
-rw-------. root root system_u:object_r:krb5_host_rcache_t:s0 /var/tmp/host_0


I should add that most of the i915_gem issues show up as kernel oops. It's currently number 1 on http://www.kerneloops.org/. I typically just keep using my system after an oops. If I didn't it would be unusable. I do recall that for a while at about the same time that I was having the display manager crashes I was occasionally also having quite a few kernel oops issues.

Comment 9 Tim Scofield 2009-07-09 22:32:28 UTC
Not quite sure how it's happening, but now

ls -lZ /var/tmp/host_0
-rw-------. root root system_u:object_r:local_login_tmp_t:s0 /var/tmp/host_0
ls -l /var/tmp/host_0
-rw-------. 1 root root 88 2009-07-09 15:32 /var/tmp/host_0

/var/log/messages shows the following around this time:
Jul  9 15:21:34 s911123 yum: Installed: 1:dejagnu-1.4.4-14.fc11.noarch
Jul  9 15:33:04 s911123 kernel: workrave[2695]: segfault at 1c08fb80 ip 00000036e6436745 sp 00007f8d7e1c9bb0 error 4 in libc-2.10.1.so[36e6400000+164000]
Jul  9 15:33:05 s911123 kdm[2005]: X server for display :0 terminated unexpectedly
Jul  9 15:33:21 s911123 kernel: [drm] TMDS-14: set mode 1280x1024 2f
Jul  9 15:33:23 s911123 bonobo-activation-server (twscofi-8372): could not associate with desktop session: Failed to connect to socket /tmp/dbus-Ug8T9wwCc8: Connection refused
Jul  9 15:33:36 s911123 setroubleshoot: SELinux is preventing kdm (xdm_t) "getattr" to /var/tmp/host_0 (local_login_tmp_t). For complete SELinux messages. run sealert -l cb163845-1ace-4d54-ab37-cbb873c7f2f1
Jul  9 15:33:37 s911123 kernel: [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
Jul  9 15:33:37 s911123 kernel: ------------[ cut here ]------------
Jul  9 15:33:37 s911123 kernel: WARNING: at drivers/gpu/drm/i915/i915_gem_tiling.c:313 i915_gem_set_tiling+0x491/0x4ed [i915]() (Tainted: G        W )

My kernel is tainted because it's crashed too many times
ls -l --full-time /var/tmp/host_0
-rw-------. 1 root root 88 2009-07-09 15:32:55.920750473 -0600 /var/tmp/host_0

I'm assuming that the relabeling is what's updating the timestamp, roughly 8 seconds before my system became completely unresponsive (8 seconds is a long time for a computer though).

Comment 10 Daniel Walsh 2009-07-10 12:26:43 UTC
ls -lZ /var/tmp/host_0
-rw-------. root root system_u:object_r:local_login_tmp_t:s0 /var/tmp/host_0

This indicates the host_0 file was created when you logged in via the console?

/bin/login created files in /tmp labeled as local_login_tmp_t, the kerberos libraries are supposed to fix the context.

If you remove the file and login via the console does it get the correct context?  

If Yes, did you login to this system via some other mechanism?  Was the file labeled correct and then suddenly it was labeled incorrectly?  Or had you removed it and it got created with the wrong context.  

I do not believe the kernel crash had anything to do with this file being mislabeled.