Bug 1646521

Summary: firefox cannot run in SELinux sandbox
Product: Red Hat Enterprise Linux 7 Reporter: Milos Malik <mmalik>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.6CC: jfrieben, lvrabec, mmalik, plautrba, ssekidde, vmojzis
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 12:52:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1653106    

Description Milos Malik 2018-11-05 15:56:05 UTC
Description of problem:
 * SELinux policy contains type transition rules for various sandbox processes which create temporary files in directories labeled tmpfs_t, but similar rules for creating files in directories labeled tmp_t are missing

Version-Release number of selected component (if applicable):
firefox-60.2.2-1.el7_5.x86_64
policycoreutils-sandbox-2.5-29.el7.x86_64
selinux-policy-sandbox-3.13.1-229.el7_6.5.noarch

How reproducible:
 * always

Steps to Reproduce:
1. get a RHEL-7.6 machine
2. log into X session as unconfined user
3. run: sandbox -X firefox

Actual results:
 * firefox does NOT start in sandbox environment

----
type=PROCTITLE msg=audit(11/05/2018 16:22:56.894:1928) : proctitle=/usr/bin/Xephyr -resizeable -title Sandbox sandbox_x_t:s0:c815,c876 --  /usr/bin/firefox  -terminate -reset -screen 1000x700 -dp 
type=SYSCALL msg=audit(11/05/2018 16:22:56.894:1928) : arch=x86_64 syscall=recvmsg success=yes exit=32 a0=0x6 a1=0x7fff6e213770 a2=0x0 a3=0x7fff6e2134a0 items=0 ppid=12675 pid=12684 auid=unconfined-user uid=unconfined-user gid=unconfined-user euid=unconfined-user suid=unconfined-user fsuid=unconfined-user egid=unconfined-user sgid=unconfined-user fsgid=unconfined-user tty=(none) ses=7 comm=Xephyr exe=/usr/bin/Xephyr subj=unconfined_u:unconfined_r:sandbox_xserver_t:s0:c815,c876 key=(null) 
type=AVC msg=audit(11/05/2018 16:22:56.894:1928) : avc:  denied  { write } for  pid=12684 comm=Xephyr path=/var/tmp/#384275 (deleted) dev="dm-0" ino=384275 scontext=unconfined_u:unconfined_r:sandbox_xserver_t:s0:c815,c876 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0 
----

Expected results:
 * limited firefox starts in sandbox environment

Additional info:
After loading a custom policy module (just 1 line) the firefox works in enforcing mode:

# cat mypolicy.cil
( allow sandbox_xserver_t user_tmp_t ( file ( write )))
# semodule -i mypolicy.cil
#

Comment 2 Lukas Vrabec 2019-01-07 15:16:49 UTC
*** Bug 1663876 has been marked as a duplicate of this bug. ***

Comment 5 Milos Malik 2019-04-30 12:59:28 UTC
An unconfined user can run firefox in sandbox using following commands:
 1) sandbox -X firefox
 2) sandbox -X -t sandbox_min_t firefox
 3) sandbox -X -t sandbox_net_t firefox
 4) sandbox -X -t sandbox_x_t firefox
 5) sandbox -X -t sandbox_web_t firefox

Firefox starts and runs successfully in all above-mentioned cases. Firefox can access network in cases 2, 3, 5. Firefox cannot access network in cases 1 and 5, which is expected. These commands trigger various SELinux denials which are expected because of the nature of sandbox.
 
# rpm -qa selinux\* \*sandbox\* | sort
policycoreutils-sandbox-2.5-31.el7.x86_64
selinux-policy-3.13.1-245.el7.noarch
selinux-policy-devel-3.13.1-245.el7.noarch
selinux-policy-mls-3.13.1-245.el7.noarch
selinux-policy-sandbox-3.13.1-245.el7.noarch
selinux-policy-targeted-3.13.1-245.el7.noarch
# sesearch -s sandbox_xserver_t -t user_tmp_t -c file -A -C -p write
Found 1 semantic av rules:
   allow sandbox_xserver_t user_tmp_t : file { ioctl read write getattr lock append map open } ; 

#

Comment 7 errata-xmlrpc 2019-08-06 12:52:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2127