Bug 711074

Summary: SELinux is preventing /usr/bin/Xephyr from 'name_connect' accesses on the tcp_socket port 6000.
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 14CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:874ccbaebe5c3dc0bf853df4b656fe630a6c81f96020e2c626f1474d58a478f8
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-23 22:51:07 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 Mads Kiilerich 2011-06-06 13:08:32 UTC
SELinux is preventing /usr/bin/Xephyr from 'name_connect' accesses on the tcp_socket port 6000.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that Xephyr should be allowed name_connect access on the port 6000 tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep Xephyr /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_xserver_t:s0:c19
                              3,c635
Target Context                system_u:object_r:xserver_port_t:s0
Target Objects                port 6000 [ tcp_socket ]
Source                        Xephyr
Source Path                   /usr/bin/Xephyr
Port                          6000
Host                          (removed)
Source RPM Packages           xorg-x11-server-Xephyr-1.9.5-1.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-42.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.13-92.fc14.i686.PAE #1 SMP Sat
                              May 21 17:33:09 UTC 2011 i686 i686
Alert Count                   2
First Seen                    Mon 06 Jun 2011 03:04:31 PM CEST
Last Seen                     Mon 06 Jun 2011 03:04:31 PM CEST
Local ID                      f0ab75ae-1301-45b7-8ebc-54bcc9f6d9af

Raw Audit Messages
type=AVC msg=audit(1307365471.962:14961): avc:  denied  { name_connect } for  pid=3301 comm="Xephyr" dest=6000 scontext=unconfined_u:unconfined_r:sandbox_xserver_t:s0:c193,c635 tcontext=system_u:object_r:xserver_port_t:s0 tclass=tcp_socket


type=SYSCALL msg=audit(1307365471.962:14961): arch=i386 syscall=socketcall success=no exit=EACCES a0=3 a1=bfa41a30 a2=96a9dc a3=90ee418 items=0 ppid=3294 pid=3301 auid=500 uid=510 gid=510 euid=510 suid=510 fsuid=510 egid=510 sgid=510 fsgid=510 tty=(none) ses=1 comm=Xephyr exe=/usr/bin/Xephyr subj=unconfined_u:unconfined_r:sandbox_xserver_t:s0:c193,c635 key=(null)

Hash: Xephyr,sandbox_xserver_t,xserver_port_t,tcp_socket,name_connect

audit2allow

#============= sandbox_xserver_t ==============
allow sandbox_xserver_t xserver_port_t:tcp_socket name_connect;

audit2allow -R

#============= sandbox_xserver_t ==============
allow sandbox_xserver_t xserver_port_t:tcp_socket name_connect;

Comment 1 Mads Kiilerich 2011-06-06 13:12:39 UTC
This seems to be a regression for running
  sandbox -X -t sandbox_web_t firefox

I would expect sandboxed applications to have the necessary permissions by default. But I wonder why Xephyr binds to a tcp socket - I thought it used pipes these days.

Comment 2 Daniel Walsh 2011-06-06 16:02:59 UTC
It should be using pipes.

Have you been able to repeat this or did this just happen once?

Comment 3 Mads Kiilerich 2011-06-06 16:20:56 UTC
Yes, it can be reproduced. But now I realize that it only happens if I run the sandbox inside a "su - user" shell. I am quite sure that used to work...

Comment 4 Daniel Walsh 2011-06-06 18:57:42 UTC
What happens if you run 

su - user xterm

I think you are seeing a lack of access to the .Xauthority file, wich would prevent apps from connecting directly to the Xserver.

Comment 5 Mads Kiilerich 2011-06-06 19:59:25 UTC
That fails with "cannot execute binary file". But did you mean

  su - user -c xev
or
  su - user
  xev

Both works just fine.

But when I try to "su - myself" I can run sandbox, so it might be related to .Xauthority access anyway ...

I don't see this problem on F15.