This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1462707 - firefox content process crashes under ThinLinc
firefox content process crashes under ThinLinc
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Lukas Vrabec
BaseOS QE Security Team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-19 07:24 EDT by Pierre Ossman
Modified: 2017-10-12 08:21 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-12 08:19:42 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 Pierre Ossman 2017-06-19 07:24:21 EDT
The upgrade to Firefox ESR 52 made it unusable in ThinLinc on RHEL 7 as the content process keeps crashing. After disabling dontaudit I get these AVCs:

> type=AVC msg=audit(1497779543.245:5844645): avc:  denied  { write } for  pid=14040 comm="plugin-containe" path="/var/opt/thinlinc/sessions/ossman/1/xinit.log" dev="dm-0" ino=53426598 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:thinlinc_user_t:s0 tclass=file
> type=AVC msg=audit(1497779543.319:5844646): avc:  denied  { search } for  pid=14040 comm="plugin-containe" name="ossman" dev="dm-0" ino=53427253 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:thinlinc_user_dir_t:s0 tclass=dir
> type=AVC msg=audit(1497779543.319:5844646): avc:  denied  { search } for  pid=14040 comm="plugin-containe" name="1" dev="dm-0" ino=53427204 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:thinlinc_user_t:s0 tclass=dir

The first line is the session log file (stderr for most processes). The following two lines may be when it is digging for Xauthority.

Under both RHEL 6 and Fedora 25 the content process is running as unconfined_t. The newer Firefox in Fedora 25 also avoids using plugin-container for content processes.

Downstream report:

https://www.cendio.com/bugzilla/show_bug.cgi?id=6993


I would be very happy if someone could have a look at this given how severely Firefox is affected by this. Disabling e10s in Firefox could be an option and re-enable it once Firefox is updated to something not using plugin-container.
Comment 2 Lukas Vrabec 2017-06-20 06:30:50 EDT
Pierre, 

thinlinc_user_t SELinux domain is not part of RHEL or Fedora distribution policy. These allow rules should be fixed in thinlinc SELinux security module. 

Closing this BZ as CANTFIX.
Comment 3 Pierre Ossman 2017-06-20 07:37:03 EDT
Well, we don't want to allow plugins free reign without a bit more understanding of things. Like:

 a) Why is plugin-container used for content processes on RHEL, but not Fedora?

 b) Why is it running as unconfined_t on RHEL 6 but not RHEL 7? If it's okay for 6 then can't you do the same for 7?
Comment 4 Pierre Ossman 2017-06-20 09:32:49 EDT
I can remove ThinLinc from the equation, making this more general. Any scenario where $XAUTHORITY is somewhere uncommon tends to break. E.g. with NX:

$ XAUTHORITY=/usr/NX/home/nx/.Xauthority firefox

Leads to:

> type=AVC msg=audit(1497965378.813:547): avc:  denied  { search } for  pid=6843 comm="plugin-containe" name="home" dev="dm-0" ino=67767068 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:nx_server_var_lib_t:s0 tclass=dir
Comment 5 Milos Malik 2017-06-21 02:40:20 EDT
SELinux policy for both RHEL-6 and RHEL-7 defines a boolean called unconfined_mozilla_plugin_transition, which can influence whether the transition to mozilla_plugin_t happens.
Comment 6 Pierre Ossman 2017-06-21 03:45:57 EDT
Ah, indeed. And the default seems to be different between RHEL 6 and RHEL 7 which explains why RHEL 6 works and RHEL 7 doesn't. So this could happen on some RHEL 6 systems as well I guess.

Wouldn't it be reasonable to just allow 'search' on all dirs for mozilla_plugin_t? Requiring the Xauthority file to be tagged xauth_home_t is fine, but restricting every folder in the path up to it to specific types seems excessive.

I'm not quite sure of the syntax, but something like:

  allow mozilla_plugin_t file_type:dir search;
Comment 7 Lukas Vrabec 2017-10-12 08:19:42 EDT
We're going to close this bug as WONTFIX because

 * of limited capacity of selinux-policy developers
 * the bug is related to EPEL component or 3rd party SW only
 * the bug appears in unsupported configuration 

We believe this bug can be fixed via a local policy module.
For more information please see: 

 * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow

If you disagree, please re-open the bug.
Comment 8 Lukas Vrabec 2017-10-12 08:21:32 EDT
We're going to close this bug as WONTFIX because

 * of limited capacity of selinux-policy developers
 * the bug is related to EPEL component or 3rd party SW only
 * the bug appears in unsupported configuration 

We believe this bug can be fixed via a local policy module.
For more information please see: 

 * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow

If you disagree, please re-open the bug.

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