Bug 1017727 - Sandboxed Firefox is hidden
Sandboxed Firefox is hidden
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
22
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-10 07:58 EDT by Germano Massullo
Modified: 2016-07-19 15:27 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 15:27:25 EDT
Type: Bug
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 Germano Massullo 2013-10-10 07:58:54 EDT
Description of problem:
In console if I enter the command
sandbox -X -t sandbox_web_t firefox
the console behaves like if the process is running, but the window does not appear on the screen.


Additional info:
# rpm -qa *selinux*
libselinux-devel-2.1.13-15.fc19.x86_64
selinux-policy-targeted-3.12.1-74.8.fc19.noarch
selinux-policy-doc-3.12.1-74.8.fc19.noarch
selinux-policy-devel-3.12.1-74.8.fc19.noarch
selinux-policy-3.12.1-74.8.fc19.noarch
libselinux-2.1.13-15.fc19.i686
libselinux-python-2.1.13-15.fc19.x86_64
libselinux-2.1.13-15.fc19.x86_64
libselinux-utils-2.1.13-15.fc19.x86_64

# rpm -qa policycoreutils*
policycoreutils-sandbox-2.1.14-46.6.fc19.x86_64
policycoreutils-gui-2.1.14-46.6.fc19.x86_64
policycoreutils-devel-2.1.14-46.6.fc19.x86_64
policycoreutils-2.1.14-46.6.fc19.x86_64
policycoreutils-python-2.1.14-46.6.fc19.x86_64

This is not happening on the computer that gave the trouble of bugreport
https://bugzilla.redhat.com/show_bug.cgi?id=1015614
Comment 1 Miroslav Grepl 2013-10-10 09:02:41 EDT
Lukas, 
any chance to re-produce it on your F19 system?
Comment 2 Lukas Vrabec 2013-10-10 09:26:33 EDT
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
Comment 3 Daniel Walsh 2013-10-10 13:32:15 EDT
 Germano


Does 
sandbox -X evince
 work?
Comment 4 Germano Massullo 2013-10-10 14:03:20 EDT
I don't have evince, so I tried
sandbox -X okular
and the result is the same
Comment 5 Daniel Walsh 2013-10-10 14:10:11 EDT
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
Comment 6 Germano Massullo 2013-10-10 14:22:34 EDT
(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


??
Comment 7 Daniel Walsh 2013-10-10 15:32:59 EDT
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.
Comment 8 Germano Massullo 2013-10-10 17:20:49 EDT
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
Comment 9 Daniel Walsh 2013-10-11 13:07:44 EDT
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
Comment 10 Germano Massullo 2013-10-11 15:13:51 EDT
(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.
Comment 11 Daniel Walsh 2013-10-16 15:03:14 EDT
Did 
sandbox -id -Z 
work?

Did it show any output?
Comment 12 Germano Massullo 2013-10-16 18:29:56 EDT
$ sandbox -id -Z
/usr/bin/sandbox: d not found
Comment 13 Daniel Walsh 2013-10-17 09:25:28 EDT
Sorry

sandbox id -Z
Comment 14 Germano Massullo 2013-10-17 09:32:39 EDT
$ sandbox id -Z
unconfined_u:unconfined_r:sandbox_t:s0:c182,c804
Comment 15 Daniel Walsh 2013-10-17 11:14:30 EDT
Ok so at least at this level sandbox is working.  Now lets see if it is mounting content.

sandbox -M ls -lZd .
Comment 16 Germano Massullo 2013-10-17 12:15:58 EDT
$ 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
Comment 17 Daniel Walsh 2013-10-17 13:10:52 EDT
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?
Comment 18 Germano Massullo 2013-10-17 13:16:40 EDT
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.
Comment 19 Daniel Walsh 2013-10-17 14:14:10 EDT
If you run 

~/.sandboxrc

Xterm works?

If yes

run 

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

And attach the output.
Comment 20 Germano Massullo 2013-10-17 14:54:08 EDT
$ 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
Comment 21 Daniel Walsh 2013-10-18 08:55:05 EDT
 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
Comment 22 Daniel Walsh 2013-10-18 08:56:52 EDT
Looks like there might be something wrong with Xephyr.

Xephyr -displayfd 5

Does a window comeup?
Comment 23 Germano Massullo 2013-10-20 17:50:30 EDT
(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
Comment 24 Daniel Walsh 2013-10-22 14:01:34 EDT
If you run 

> Xephyr -displayfd 5

in a console window does a window appear?
Comment 25 Germano Massullo 2013-10-22 14:06:56 EDT
(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
Comment 26 Daniel Walsh 2013-10-29 11:40:38 EDT
Then I believe this is a bug in Xephyr
Comment 27 Germano Massullo 2014-12-16 04:50:07 EST
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
====================
Comment 28 Fedora End Of Life 2015-05-29 05:33:02 EDT
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.
Comment 29 Fedora End Of Life 2016-07-19 15:27:25 EDT
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.

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