Bug 604913

Summary:	SELinux is preventing /usr/bin/Xephyr "name_bind" access .
Product:	[Fedora] Fedora	Reporter:	Josh <jokajak>
Component:	selinux-policy	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	13	CC:	dwalsh, mgrepl
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:	setroubleshoot_trace_hash:3765aa7ba69d1af52146fb83a002c141c04d51d7d7be7e5877f51d1e9b2eb848
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-19 10:07:31 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 Josh 2010-06-17 01:26:16 UTC

I was trying to use:
$ sandbox -X -H ~/dir/home -T ~/dir/tmp firefox

Summary:

SELinux is preventing /usr/bin/Xephyr "name_bind" access .

Detailed Description:

SELinux denied access requested by Xephyr. It is not expected that this access
is required by Xephyr and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                unconfined_u:unconfined_r:sandbox_xserver_t:s0:c13
                              0,c505
Target Context                system_u:object_r:varnishd_port_t:s0
Target Objects                None [ tcp_socket ]
Source                        Xephyr
Source Path                   /usr/bin/Xephyr
Port                          6082
Host                          (removed)
Source RPM Packages           xorg-x11-server-Xephyr-1.8.0-12.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-23.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) 2.6.33.5-124.fc13.i686.PAE #1 SMP Fri
                              Jun 11 09:42:24 UTC 2010 i686 i686
Alert Count                   66
First Seen                    Wed 16 Jun 2010 09:21:56 PM EDT
Last Seen                     Wed 16 Jun 2010 09:22:58 PM EDT
Local ID                      701566df-9996-4b19-9121-e26272b2a853
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1276737778.263:40217): avc:  denied  { name_bind } for  pid=3970 comm="Xephyr" src=6082 scontext=unconfined_u:unconfined_r:sandbox_xserver_t:s0:c130,c505 tcontext=system_u:object_r:varnishd_port_t:s0 tclass=tcp_socket

node=(removed) type=SYSCALL msg=audit(1276737778.263:40217): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfb9ef10 a2=824c824 a3=12 items=0 ppid=3963 pid=3970 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="Xephyr" exe="/usr/bin/Xephyr" subj=unconfined_u:unconfined_r:sandbox_xserver_t:s0:c130,c505 key=(null)



Hash String generated from  catchall,Xephyr,sandbox_xserver_t,varnishd_port_t,tcp_socket,name_bind
audit2allow suggests:

#============= sandbox_xserver_t ==============
allow sandbox_xserver_t varnishd_port_t:tcp_socket name_bind;

Comment 1 Miroslav Grepl 2010-06-17 07:50:07 UTC

How did you get this to happen?  Why is your X server using port 6081 or 6082?

Comment 2 Daniel Walsh 2010-06-17 13:13:06 UTC

Does

$ sandbox -X -H ~/dir/home -T ~/dir/tmp -t sandbox_web_t firefox

Work.

Comment 3 Josh 2010-06-18 00:07:02 UTC

It works the first time but doesn't work the second time.  IE:

$ rm -rf ~/dir
$ mkdir -p ~/dir/{home,tmp}
$ sandbox -X -H ~/dir/home -T ~/dir/tmp -t sandbox_web_t firefox # works
< quit firefox >
$ sandbox -X -H ~/dir/home -T ~/dir/tmp -t sandbox_web_t firefox # doesn't work

additionally, the second sandbox just hangs there.  If I send it a ctrl+c it returns me to a prompt but the sandbox process is still running and has to be killed via its pid.

Specifying the level that is what the files are labeled doesn't work due to a bug in __setup_dir that returns from the function before defining self.__homedir and self.__tmpdir.  Even after fixing that bug it still does not work.

Comment 4 Josh 2010-06-18 00:12:55 UTC

(In reply to comment #3)
> It works the first time but doesn't work the second time.  IE:
> 
> $ rm -rf ~/dir
> $ mkdir -p ~/dir/{home,tmp}
> $ sandbox -X -H ~/dir/home -T ~/dir/tmp -t sandbox_web_t firefox # works
> < quit firefox >
> $ sandbox -X -H ~/dir/home -T ~/dir/tmp -t sandbox_web_t firefox # doesn't work
> 
> additionally, the second sandbox just hangs there.  If I send it a ctrl+c it
> returns me to a prompt but the sandbox process is still running and has to be
> killed via its pid.
> 
> Specifying the level that is what the files are labeled doesn't work due to a
> bug in __setup_dir that returns from the function before defining
> self.__homedir and self.__tmpdir.  Even after fixing that bug it still does not
> work.    

Correction, it does fix it.  It seems the problem is that the chcon isn't properly relabeling all of the files.

-josh

Comment 5 Daniel Walsh 2010-06-18 14:26:45 UTC

Josh 

killall restorecond

And then try it.

Comment 6 Josh 2010-06-19 01:44:59 UTC

restorecond is not running, still doesn't work

i think the chcon isn't working for some reason

Comment 7 Daniel Walsh 2010-07-29 16:46:02 UTC

Sorry dropped this one.


ps -eZ | grep restorecon

Are you sure.  A restorecond user daemon starts at login.