Bug 1474082 - sandbox -X no longer working, SELinux violations
sandbox -X no longer working, SELinux violations
Status: NEW
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
27
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-23 14:37 EDT by Dimitris
Modified: 2017-12-15 12:22 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 Dimitris 2017-07-23 14:37:35 EDT
Description of problem:

Looks like a regression from F25 (or F24, not quite sure).

Version-Release number of selected component (if applicable):

2.6-5.fc26

How reproducible:

Every time

Steps to Reproduce:
1. run `sandbox -X -t sandbox_x_t evince /tmp/file.pdf`
2. Nested X Server window momentarily pops up
2. Fails, apparently due to a number of SELinux denials


Actual results:

Can't execute evince in X sandbox like I used to

Expected results:

Used to be able to use sandboxed evince for random PDFs

Additional info:

Two AVCs:

SELinux is preventing evince from write access on the directory /run/user/1000.

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

If you believe that evince should be allowed write access on the 1000 directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'evince' --raw | audit2allow -M my-evince
# semodule -X 300 -i my-evince.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_x_t:s0:c483,c904
Target Context                system_u:object_r:user_tmp_t:s0
Target Objects                /run/user/1000 [ dir ]
Source                        evince
Source Path                   evince
Port                          <Unknown>
Host                          vimes
Source RPM Packages           
Target RPM Packages           
Policy RPM                    <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     vimes
Platform                      Linux vimes 4.11.11-300.fc26.x86_64 #1 SMP Mon Jul
                              17 16:32:11 UTC 2017 x86_64 x86_64
Alert Count                   6
First Seen                    2017-07-23 11:26:57 PDT
Last Seen                     2017-07-23 11:26:58 PDT
Local ID                      e9610547-cb4f-4010-97cc-196bb6b75ae1

Raw Audit Messages
type=AVC msg=audit(1500834418.306:1418): avc:  denied  { write } for  pid=24349 comm="xdg-desktop-por" name="/" dev="tmpfs" ino=35074 scontext=unconfined_u:unconfined_r:sandbox_x_t:s0:c483,c904 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir permissive=0


Hash: evince,sandbox_x_t,user_tmp_t,dir,write


and:


SELinux is preventing evince from read access on the lnk_file /var/lib/dbus/machine-id.

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

If you believe that evince should be allowed read access on the machine-id lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'evince' --raw | audit2allow -M my-evince
# semodule -X 300 -i my-evince.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_x_t:s0:c483,c904
Target Context                system_u:object_r:system_dbusd_var_lib_t:s0
Target Objects                /var/lib/dbus/machine-id [ lnk_file ]
Source                        evince
Source Path                   evince
Port                          <Unknown>
Host                          vimes
Source RPM Packages           
Target RPM Packages           
Policy RPM                    <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     vimes
Platform                      Linux vimes 4.11.11-300.fc26.x86_64 #1 SMP Mon Jul
                              17 16:32:11 UTC 2017 x86_64 x86_64
Alert Count                   1
First Seen                    2017-07-23 11:26:58 PDT
Last Seen                     2017-07-23 11:26:58 PDT
Local ID                      03107ff5-6e62-4322-9a8b-862ee82682b6

Raw Audit Messages
type=AVC msg=audit(1500834418.358:1420): avc:  denied  { read } for  pid=24300 comm="evince" name="machine-id" dev="dm-1" ino=12451917 scontext=unconfined_u:unconfined_r:sandbox_x_t:s0:c483,c904 tcontext=system_u:object_r:system_dbusd_var_lib_t:s0 tclass=lnk_file permissive=0


Hash: evince,sandbox_x_t,system_dbusd_var_lib_t,lnk_file,read
Comment 1 Petr Lautrbach 2017-12-15 08:13:11 EST
It's related to Wayland. The same command works with X.org.

When Wayland is used, there are file like '/run/user/1001/wayland-cursor-shared-2Xw77u' created, mapped and removed. And it's not allowed in the current policy.

The following rules should allow 'sandbox -X' to run applications in Wayland in Fedora 26:

allow sandbox_x_t user_tmp_t:dir {  write add_name remove_name };
allow sandbox_x_t user_tmp_t:file {  map create unlink };
allow sandbox_x_t sandbox_x_client_tmpfs_t:file { map };


In Fedora 27 we support nnp_transition therefore we can use them:

allow sandbox_x_t sandbox_x_client_t:process2 nnp_transition;                            
allow sandbox_x_t sandbox_xserver_t:process2 nnp_transition;                             
                                                                                         allow sandbox_x_client_t user_tmp_t:dir {  write add_name remove_name };                   
allow sandbox_x_client_t user_tmp_t:file {  map create unlink };                           
allow sandbox_x_client_t sandbox_x_client_tmpfs_t:file { map };                            

Note, I need to do more investigation around Wayland and how to use it and investigate a possible impact of the rules above. For now you can either switch to X.org or use the rules in a local temporary policy.
Comment 2 Dimitris 2017-12-15 12:22:54 EST
Just updating to F27 (still reproduces)

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