Bug 459343 - nspluginwrapper, remote display, selinux issues
nspluginwrapper, remote display, selinux issues
Product: Fedora
Classification: Fedora
Component: nspluginwrapper (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
: SELinux
Depends On:
  Show dependency treegraph
Reported: 2008-08-16 21:42 EDT by Carl Roth
Modified: 2009-02-24 11:17 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-24 11:17:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Carl Roth 2008-08-16 21:42:58 EDT
Description of problem:

Firefox plugins are not working for me in the following configuration:

* plugins wrapped using nspluginwrapper
* firefox running on a remote display (i.e. via 'ssh -X')
* selinux enabled (enforcing mode)

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


How reproducible:


Steps to Reproduce:
1. configure selinux in enforcing mode
2. log into the host with 'ssh -X'
3. launch firefox
4. try to view a page with embedded objects

Actual results:

* plugin does not display (blank grey canvas)
* console reports

  (npviewer.bin:PID): Gtk-WARNING **: cannot open display: REMOTE-DISPLAY-SPEC
  *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection

Expected results:

Additional info:

If the display is local (:0) the plugins work fine.
If I disable selinux (setenforce 0) the plugins work fine.

I tried to diagnose the issue a bit, as follows:

* I noted that the gtk display warning seems to be from a pretty basic display init function, so I tried

  $ unset DISPLAY  
  $ python
  > import gtk
  RuntimeError: could not open display

OK, maybe related

  $ python
  > import gtk

no, that wasn't it.  I'm not a gtk programmer so I can't really pursue this line further.  On the other hand, this is python running unconfined, whereas the plugin is probably running confined?

* then I crawled around the nspluginwrapper sources to see if I could reproduce the RPC attempt...  It turns out I can trigger this by invoking the 'npviewer.bin' program with fake arguments:

  $ DISPLAY=:0
  $ /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/mozplugger.so --connection /tmp/foo
  <<program stalls waiting for RPC>>

... that looks promising

  $ /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/mozplugger.so --connection /tmp/foo
  (npviewer.bin:PID): Gtk-WARNING **: cannot open display: REMOTE-DISPLAY-SPEC

... this seems to reproduce the issue in the bug report

  $ sudo setenforce 0
  $ /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/mozplugger.so --connection /tmp/foo
  <<program stalls waiting for RPC>> 

... hey that's interesting, now it seems to work.

This is where my debugging sort of trails off...  I'm guessing there's a 'dontaudit' somewhere in the policy that's preventing the access that Gtk is attempting.  I forgot what the tweak is to get selinux to undo all of the 'dontaudit' rules.

I ran 'strace' on the second-to-last example (fails when selinux is enforcing) and the end of the strace reports

4394  connect(4, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("")}, 16) = -1 EACCES (Permission denied)
4394  write(2, "\n(npviewer.bin:4394): Gtk-WARNIN"..., 74) = 74

... here we see that the npviewer.bin application that I'm tracing is not allowed to connect to localhost:10.  Is there a rule for nsplugin_t that's missing here?
Comment 1 Daniel Walsh 2008-08-18 06:57:37 EDT
Do you have an avc message?

nsplugin_t is a locked down domain that we are trying to prevent from talking to the network, so most likely there is an issue here with your setup.  I would like to know the specific avc that you are seeing.

You have 

turned on which is causing the nsplugin process to be confined.
Comment 2 Warren Togami 2008-08-18 10:09:51 EDT
> nsplugin_t is a locked down domain that we are trying to prevent from 
> talking to the network

We're disallowing nspluginwrapper from talking to the network entirely?
Comment 3 Daniel Walsh 2008-08-28 16:33:02 EDT

As well as dns, and ldap for UID verification.

sesearch --allow | grep nsplugin_t | grep name_connect
WARNING: This policy contained disabled aliases; they have been removed.
   allow nsplugin_t ldap_port_t : tcp_socket { recv_msg send_msg name_connect }; 
   allow nsplugin_t dns_port_t : tcp_socket { recv_msg send_msg name_connect }; 
   allow nsplugin_t flash_port_t : tcp_socket name_connect ; 
   allow nsplugin_t http_port_t : tcp_socket name_connect ; 
   allow nsplugin_t pulseaudio_port_t : tcp_socket name_connect ; 
   allow nsplugin_t kerberos_port_t : tcp_socket { recv_msg send_msg name_connect }; 
   allow nsplugin_t ocsp_port_t : tcp_socket name_connect ; 

Removed some additional ports that are allowed if you use NIS.
Comment 4 Daniel Walsh 2008-08-28 16:35:01 EDT
You should be able to allow this by executing

# grep nsplugin /var/log/audit/audit.log | audit2allow -m mynsplugin
# semodule -i mynsplugin.pp
Comment 5 Warren Togami 2009-02-18 11:41:51 EST
Is this still an issue now?  Is SELinux blocking Flash from working by default policies?
Comment 6 Daniel Walsh 2009-02-18 13:03:31 EST
No, it is only a problem if you are transitioning to nsplugin, which is not the default.

nsplugin_can_network boolean has been added to Rawhide to allow it to connect to all network ports > 1023
Comment 7 Carl Roth 2009-02-21 15:08:06 EST
hm, now that I have upgraded my system to F10 I am getting a completely different problem trying to launch a remote firefox.  Firefox throws up a dialog box that says

"An error occurred while loading or saving configuration information for firefox.  Some of your configuration settings may not work properly."

... and firefox will not start.

I see a similar message described in BUG471114, but for a different reason.
Comment 8 Daniel Walsh 2009-02-23 10:44:25 EST
Are you seeing AVC messages in /var/log/audit/audit.log?

Have you yum updated to the latest selinux-policy-targeted?
Comment 9 Carl Roth 2009-02-24 11:17:55 EST
Sorry, I was mistaken.  It's actually the case that firefox *does* run with a remote display (YouTube and all) but I still do get the annoying dialog boxes about "configuration information".  This is a separate issue unrelated to selinux I think.

For the record, this system is running


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