Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1079034

Summary: SELinux prevents X11 forwarding
Product: Red Hat Enterprise Linux 6 Reporter: Gabriel Redner <gredner>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: dwalsh, gredner, mmalik
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-28 10:15:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Snippet from /var/log/audit/audit.log encompassing the commands in 'steps to reproduce'
none
Output of ausearch command after connecting via ssh -X none

Description Gabriel Redner 2014-03-20 19:37:01 UTC
Created attachment 877001 [details]
Snippet from /var/log/audit/audit.log encompassing the commands in 'steps to reproduce'

Description of problem:

SELinux policy is preventing X11 forwarding from working, possibly by denying access to ~/.Xauthority or xauth lock files.


Version-Release number of selected component (if applicable):

[gredner@capsid ~]$ lsb_release -a
LSB Version:	:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID:	RedHatEnterpriseServer
Description:	Red Hat Enterprise Linux Server release 6.5 (Santiago)
Release:	6.5
Codename:	Santiago
[gredner@capsid ~]$ uname -a
Linux capsid.brandeis.edu 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:

100%


Steps to Reproduce:

From another machine (Linux Mint in this case, but it doesn't matter), connect via ssh -X and try to run xauth or any program that wants to display an X11 window.


Actual results:

other-machine$ ssh -X capsid.brandeis.edu
/usr/bin/xauth:  timeout in locking authority file /home/gredner/.Xauthority
[gredner@capsid ~]$ xauth
xauth:  timeout in locking authority file /home/gredner/.Xauthority


Expected results:

It should work!


Additional info:

I believe the problem is SELinux related because when I set SELinux to permissive mode, everything works, and when I return it to enforcing mode the problem returns.

Strangely, SELinux does not print any messages in its log which indicate the problem (see attached auth.log).

Some searching has turned up several instances of similar problems:

https://bugzilla.redhat.com/show_bug.cgi?id=772992
http://jermdemo.blogspot.com/2011/10/selinux-for-enhanced-headaches.html
http://lists.centos.org/pipermail/centos/2012-January/122278.html

However, the proposed solutions in those links do not work or do not apply:

- My home directory has the correct SELinux context:
[gredner@capsid ~]$ ls -dZ .
drwx------. gredner gredner unconfined_u:object_r:user_home_dir_t:s0 .

- My .Xauthority file has the correct permissions and SELinux context:
[gredner@capsid ~]$ ls -lZ .Xauthority 
-rw-------. gredner gredner unconfined_u:object_r:xauth_home_t:s0 .Xauthority

- I am not using NFS home dirs


I suppose this bug has three parts:

1. How is SELinux blocking something while not logging that action?
2. Why is SELinux preventing X11 forwarding?
3. How can I placate SELinux so it will allow X11 forwarding?

Comment 2 Miroslav Grepl 2014-03-24 09:23:14 UTC
Is auditd running? If yes, you probably will need to turn off dontaudit rules 

# semodule -DB

re-test it and

# ausearch -m avc,user_avc -ts recent

Comment 3 Gabriel Redner 2014-03-24 19:15:23 UTC
Auditd is running:

[root@capsid ~]# ps aux | grep auditd
root      1084  0.0  0.0      0     0 ?        S    Mar21   0:01 [kauditd]
root      1312  0.0  0.0  27640   640 ?        S<sl Mar21   0:03 auditd
root     32428  0.0  0.0 103256   832 pts/1    S+   15:06   0:00 grep auditd

I ran:
# semodule -DB

which produced no output.  

When I connected to the box via ssh -X, the same problem recurred, but now messages do appear in the audit log.

I am attaching the output of 
# ausearch -m avc,user_avc -ts recent

as ausearch.log.  I have read through it, but it's still not clear to me exactly what access is being denied or why.

Comment 4 Gabriel Redner 2014-03-24 19:15:55 UTC
Created attachment 878147 [details]
Output of ausearch command after connecting via ssh -X

Comment 5 Milos Malik 2014-03-27 05:51:38 UTC
I believe the problem is here:
----
time->Mon Mar 24 15:09:24 2014
type=SYSCALL msg=audit(1395688164.841:79506): arch=c000003e syscall=2 success=no exit=-13 a0=7fffbefe4180 a1=c1 a2=180 a3=8 items=0 ppid=402 pid=403 auid=515 uid=515 gid=516 euid=515 suid=515 fsuid=515 egid=516 sgid=516 fsgid=516 tty=pts2 ses=1262 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1395688164.841:79506): avc:  denied  { read } for  pid=403 comm="xauth" name="gredner" dev=sdb1 ino=3227 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=lnk_file
----

It seems that your home directory is a symlink and current policy prevents xauth from reading where the symlink points to. The fix should be easy:

# cat mypolicy.te
module mypolicy 1.0;
require {
        type xauth_t;
        type user_home_dir_t;
        class lnk_file read;
}
allow xauth_t user_home_dir_t:lnk_file read;

# make -f /usr/share/selinux/devel/Makefile
Compiling targeted mypolicy module
/usr/bin/checkmodule:  loading policy configuration from tmp/mypolicy.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/mypolicy.mod
Creating targeted mypolicy.pp policy package
rm tmp/mypolicy.mod.fc tmp/mypolicy.mod

# semodule -i mypolicy.pp

Now it should work in enforcing mode too.

BTW following command will return dontaudit rules to active policy:
# semodule -B

Comment 6 Milos Malik 2014-03-27 06:03:33 UTC
Here is another way how to do the same:

# ausearch -m avc -m user_avc -c xauth | audit2allow -M mypolicy
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i mypolicy.pp
# semodule -i mypolicy.pp
#

Now it should work in enforcing mode too.

Comment 7 Gabriel Redner 2014-03-27 14:46:31 UTC
That does fix the problem, thank you.  Sorry for the noise.

Comment 8 Daniel Walsh 2014-03-30 17:59:49 UTC
I added a fix for this in git.

62da22ed2af802ff6c070444bceb56dc4f238a50