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): firefox-3.0.1-1.fc9.x86_64 nspluginwrapper-1.1.0-5.fc9.x86_64 nspluginwrapper-1.1.0-5.fc9.i386 mozplugger-1.10.1-1.x86_64 selinux-policy-targeted-3.3.1-84.fc9.noarch How reproducible: Always 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 $ DISPLAY=REMOTE-DISPLAY-SPEC $ 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 $ DISPLAY=REMOTE-DISPLAY-SPEC $ /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 $ DISPLAY=REMOTE-DISPLAY-SPEC $ 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 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4 4394 connect(4, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, 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?
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 allow_unconfined_nsplugin_transition turned on which is causing the nsplugin process to be confined.
> 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?
corenet_tcp_connect_flash_port(nsplugin_t) corenet_tcp_connect_pulseaudio_port(nsplugin_t) corenet_tcp_connect_http_port(nsplugin_t) 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.
You should be able to allow this by executing # grep nsplugin /var/log/audit/audit.log | audit2allow -m mynsplugin # semodule -i mynsplugin.pp
Is this still an issue now? Is SELinux blocking Flash from working by default policies?
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
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.
Are you seeing AVC messages in /var/log/audit/audit.log? Have you yum updated to the latest selinux-policy-targeted?
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 flash-plugin-10.0.15.3-release.i386 firefox-3.0.6-1.fc10.x86_64 selinux-policy-targeted-3.5.13-45.fc10.noarch