Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 604913 - SELinux is preventing /usr/bin/Xephyr "name_bind" access .
SELinux is preventing /usr/bin/Xephyr "name_bind" access .
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
13
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:3765aa7ba69...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-16 21:26 EDT by Josh
Modified: 2010-08-19 06:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-19 06:07:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh 2010-06-16 21:26:16 EDT
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 03:50:07 EDT
How did you get this to happen?  Why is your X server using port 6081 or 6082?
Comment 2 Daniel Walsh 2010-06-17 09:13:06 EDT
Does

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

Work.
Comment 3 Josh 2010-06-17 20:07:02 EDT
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-17 20:12:55 EDT
(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 10:26:45 EDT
Josh 

killall restorecond

And then try it.
Comment 6 Josh 2010-06-18 21:44:59 EDT
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 12:46:02 EDT
Sorry dropped this one.


ps -eZ | grep restorecon

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

Note You need to log in before you can comment on or make changes to this bug.