Lukas, 
any chance to re-produce it on your F19 system?

No, on my system is everything OK. 

$ rpm -qa policycoreutils*
policycoreutils-restorecond-2.1.14-46.6.fc19.x86_64
policycoreutils-newrole-2.1.14-46.6.fc19.x86_64
policycoreutils-python-2.1.14-46.6.fc19.x86_64
policycoreutils-sandbox-2.1.14-46.6.fc19.x86_64
policycoreutils-2.1.14-46.6.fc19.x86_64
policycoreutils-devel-2.1.14-46.6.fc19.x86_64

$ rpm -qa libselinux*
libselinux-python-2.1.13-15.fc19.x86_64
libselinux-2.1.13-15.fc19.x86_64
libselinux-devel-2.1.13-15.fc19.x86_64
libselinux-utils-2.1.13-15.fc19.x86_64
libselinux-ruby-2.1.13-15.fc19.x86_64

 Germano


Does 
sandbox -X evince
 work?

I don't have evince, so I tried
sandbox -X okular
and the result is the same

A couple of things to try.

# chmod 4755 /usr/sbin/seunshare

See if this fixes it.

Although that is supposed to be fixed in 46.6.

Another option would be if you have a bad Xephyr.

You could try to remove "-resizeable" flag in /usr/share/sandbox/sandboxX.sh

(In reply to Daniel Walsh from comment #5)
> A couple of things to try.
> 
> # chmod 4755 /usr/sbin/seunshare

It does not fix the trouble.

> You could try to remove "-resizeable" flag in /usr/share/sandbox/sandboxX.sh
Should I remove that flag in line

(/usr/bin/Xephyr -resizeable -title "$TITLE" -terminate -screen $SCREENSIZE -dpi $DPI -nolisten tcp -displayfd 5 5>&1 2>/dev/null) | while read D; do


??

Yes
Change to 

(/usr/bin/Xephyr -title "$TITLE" -terminate -screen $SCREENSIZE -dpi $DPI -nolisten tcp -displayfd 5 5>&1 2>/dev/null) | while read D; do

And see if that fixes the problem.

The problem persists. Should I have rebooted the system before trying again?
I attach /usr/share/sandbox/sandboxX.sh


#!/bin/bash
trap "" TERM
context=`id -Z | secon -t -l -P`
export TITLE="Sandbox $context -- `grep ^#TITLE: ~/.sandboxrc | /usr/bin/cut -b8-80`"
[ -z $1 ] && export SCREENSIZE="1000x700" || export SCREENSIZE="$1"
[ -z $2 ] && export DPI="96" || export DPI="$2"
trap "exit 0" HUP
 
mkdir -p ~/.config/openbox
cat > ~/.config/openbox/rc.xml << EOF
<openbox_config xmlns="http://openbox.org/3.4/rc"
                xmlns:xi="http://www.w3.org/2001/XInclude">
<applications>
  <application class="*">
    <decor>no</decor>
    <desktop>all</desktop>
    <maximized>yes</maximized>
  </application>
</applications>
</openbox_config>
EOF
 
(/usr/bin/Xephyr -title "$TITLE" -terminate -screen $SCREENSIZE -dpi $DPI -nolisten tcp -displayfd 5 5>&1 2>/dev/null) | while read D; do
    export DISPLAY=:$D
    cat > ~/seremote << __EOF
#!/bin/sh
DISPLAY=$DISPLAY "\$@"
__EOF
    chmod +x ~/seremote
    /usr/share/sandbox/start $HOME/.sandboxrc
    export EXITCODE=$?
    kill -TERM 0
    break
done
exit 0

Ok lets start from the beginning.

does it work in permissive mode?

Are there any AVC messages showing up?

If /usr/run 

/usr/share/sandbox/sandboxX.sh

Does a window appear?

Does the following work?
# yum install selinux-policy-sandbox
# sandbox id -Z

(In reply to Daniel Walsh from comment #9)
> does it work in permissive mode?
No.

> Are there any AVC messages showing up?
No. 

> If /usr/run 
???

> /usr/share/sandbox/sandboxX.sh
> 
> Does a window appear?
No. But I get in console
grep: /home/user/.sandboxrc: File or directory does not exist

> Does the following work?
> # yum install selinux-policy-sandbox
No package selinux-policy-sandbox avaible.

> # sandbox id -Z
ERROR: could not find datum for type sandbox_t
/usr/bin/sandbox: Sandbox Policy is currently disabled.
You need to enable the policy by executing the following as root
# semodule -e sandbox




Even after entering # semodule -e sandbox  the situation has not changed.

Did 
sandbox -id -Z 
work?

Did it show any output?

$ sandbox -id -Z
/usr/bin/sandbox: d not found

Sorry

sandbox id -Z

$ sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c182,c804

Ok so at least at this level sandbox is working.  Now lets see if it is mounting content.

sandbox -M ls -lZd .

$ sandbox -M ls -lZd
drwx------. 1000 1003 unconfined_u:object_r:sandbox_file_t:s0:c272,c685 .

and I get


SELinux is preventing /usr/bin/ls from open access on the file /etc/group.

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

If si crede che ls dovrebbe avere possibilità di accesso open sui group file in modo predefinito.
Then si dovrebbe riportare il problema come bug.
E' possibile generare un modulo di politica locale per consentire questo accesso.
Do
consentire questo accesso per il momento eseguendo:
# grep ls /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_t:s0:c272,c685
Target Context                system_u:object_r:passwd_file_t:s0
Target Objects                /etc/group [ file ]
Source                        ls
Source Path                   /usr/bin/ls
Port                          <Sconosciuto>
Host                       
Source RPM Packages           coreutils-8.21-11.fc19.x86_64
Target RPM Packages           setup-2.8.71-1.fc19.noarch
Policy RPM                    selinux-policy-3.12.1-74.8.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name             
Platform                      Linux  3.11.3-201.fc19.x86_64 #1 SMP Thu
                              Oct 3 00:47:03 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-10-17 18:13:15 CEST
Last Seen                     2013-10-17 18:13:15 CEST
Local ID                     

Raw Audit Messages
type=AVC msg=audit(1382026395.213:654): avc:  denied  { open } for  pid=6533 comm="ls" path="/etc/group" dev="sdb2" ino=69752 scontext=unconfined_u:unconfined_r:sandbox_t:s0:c272,c685 tcontext=system_u:object_r:passwd_file_t:s0 tclass=file


type=SYSCALL msg=audit(1382026395.213:654): arch=x86_64 syscall=open success=no exit=EACCES a0=7f036fb5b40f a1=80000 a2=1b6 a3=0 items=0 ppid=6532 pid=6533 auid=1000 uid=1000 gid=1003 euid=1000 suid=1000 fsuid=1000 egid=1003 sgid=1003 fsgid=1003 ses=1 tty=(none) comm=ls exe=/usr/bin/ls subj=unconfined_u:unconfined_r:sandbox_t:s0:c272,c685 key=(null)

Hash: ls,sandbox_t,passwd_file_t,file,open

Good, regular sandbox is working fine for you.

But I still have no idea why it is not working for you.

Create .sandboxrc with the following content, replace xterm if you do not have xterm with another X App.

> cat > ~/.sandboxrc
#! /bin/sh
#TITLE: /usr/bin/xterm 
/usr/bin/test -r ~/.xmodmap && /usr/bin/xmodmap ~/.xmodmap
/usr/bin/openbox &
WM_PID=$!
dbus-launch --exit-with-session /usr/bin/xterm 
kill -TERM $WM_PID  2> /dev/null

> chmod 755 ~/.sandboxrc

Now run

/usr/share/sandbox/sandboxX.sh

And see if the app starts?

BTW Is your homedir standard or are you using NFS?

while in my homedir:
$ nano .sandboxrc

then putted inside

#! /bin/sh
#TITLE: /usr/bin/xterm 
/usr/bin/test -r ~/.xmodmap && /usr/bin/xmodmap ~/.xmodmap
/usr/bin/openbox &
WM_PID=$!
dbus-launch --exit-with-session /usr/bin/xterm 
kill -TERM $WM_PID  2> /dev/null

saved and runned

$ chmod 755 .sandboxrc

then

/usr/share/sandbox/sandboxX.sh

Nothing appears and the console behaves like if the process is running.

My homedir is a standard dir.

If you run 

~/.sandboxrc

Xterm works?

If yes

run 

sh -x /usr/share/sandbox/sandboxX.sh

And attach the output.

$ sh -x /usr/share/sandbox/sandboxX.sh
+ trap '' TERM
++ id -Z
++ secon -t -l -P
+ context=unconfined_t:s0
++ grep '^#TITLE:' /home/username/.sandboxrc
++ /usr/bin/cut -b8-80
+ export 'TITLE=Sandbox unconfined_t:s0 --  /usr/bin/xterm '
+ TITLE='Sandbox unconfined_t:s0 --  /usr/bin/xterm '
+ '[' -z ']'
+ export SCREENSIZE=1000x700
+ SCREENSIZE=1000x700
+ '[' -z ']'
+ export DPI=96
+ DPI=96
+ trap 'exit 0' HUP
+ mkdir -p /home/username/.config/openbox
+ cat
+ /usr/bin/Xephyr -title 'Sandbox unconfined_t:s0 --  /usr/bin/xterm ' -terminate -screen 1000x700 -dpi 96 -nolisten tcp -displayfd 5
+ read D

 sh -x /usr/share/sandbox/sandboxX.sh
+ trap '' TERM
++ id -Z
++ secon -t -l -P
+ context=staff_t:s0
++ grep '^#TITLE:' /home/dwalsh/.sandboxrc
++ /usr/bin/cut -b8-80
+ export 'TITLE=Sandbox staff_t:s0 --  /usr/bin/firefox '
+ TITLE='Sandbox staff_t:s0 --  /usr/bin/firefox '
+ '[' -z ']'
+ export SCREENSIZE=1000x700
+ SCREENSIZE=1000x700
+ '[' -z ']'
+ export DPI=96
+ DPI=96
+ trap 'exit 0' HUP
+ mkdir -p /home/dwalsh/.config/openbox
+ cat
+ /usr/bin/Xephyr -resizeable -title 'Sandbox staff_t:s0 --  /usr/bin/firefox ' -terminate -screen 1000x700 -dpi 96 -nolisten tcp -displayfd 5
+ read D
+ export DISPLAY=:2
+ DISPLAY=:2
+ cat
+ chmod +x /home/dwalsh/seremote
+ /usr/share/sandbox/start /home/dwalsh/.sandboxrc
+ export EXITCODE=0
+ EXITCODE=0
+ kill -TERM 0
+ break
+ exit 0

Looks like there might be something wrong with Xephyr.

Xephyr -displayfd 5

Does a window comeup?

(In reply to Daniel Walsh from comment #22)
> Looks like there might be something wrong with Xephyr.
> 
> Xephyr -displayfd 5
> 
> Does a window comeup?

No.
I am sorry but I do not understand comment 21

If you run 

> Xephyr -displayfd 5

in a console window does a window appear?

(In reply to Daniel Walsh from comment #24)
> If you run 
> 
> > Xephyr -displayfd 5
> 
> in a console window does a window appear?

As I wrote in comment 23, it does not appear

Then I believe this is a bug in Xephyr

After more than a year I tried again on a clean F20 install:

====================
[user@localhost ~]$ sandbox -X -t sandbox_web_t firefox
[user@localhost ~]$ 
====================
and nothing happened.

====================
[user@localhost ~]$ sandbox -X okular
[user@localhost ~]$ 
====================
and nothing happened.

====================
$ Xephyr -displayfd 5
====================
shows a black window

====================
$ sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c189,c414
====================

====================
$ sandbox -M ls -lZd
drwx------. 1000 1000 unconfined_u:object_r:sandbox_file_t:s0:c77,c250 .
====================

====================
# rpm -qa policycoreutils*
policycoreutils-2.2.5-4.fc20.x86_64
policycoreutils-sandbox-2.2.5-4.fc20.x86_64
policycoreutils-python-2.2.5-4.fc20.x86_64
====================

====================
# rpm -qa libselinux*
libselinux-2.2.1-6.fc20.i686
libselinux-utils-2.2.1-6.fc20.x86_64
libselinux-2.2.1-6.fc20.x86_64
libselinux-devel-2.2.1-6.fc20.x86_64
libselinux-python-2.2.1-6.fc20.x86_64
====================

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.