- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 5
- Why doesn't SELinux confine desktop applications?
- Why doesn't SELinux prevent the exploitation of the Mozilla Firefox vulnerability (CVE-2015-4495)?
Desktop applications are not confined by SELinux, which means they are potentially vulnerable to issues that could be prevented if SELinux controlled their activities as it does with other applications. This has been demonstrated, for example, by the Mozilla Firefox vulnerability (CVE-2015-4495), which allowed remote sessions to gain access to any local files that the Firefox application could access.
Note: The following method is only available on Red Hat Enterprise Linux 6 and higher.
Consider using the
sandbox utility, which is provided by the
policycoreutils-sandbox package, with the
-X option to run desktop applications confined in their own 'sandboxes'. This isolates the applications from the underlying system and prevents any interaction with other applications. A temporary home directory is created for the sandboxed application, which is destroyed when the application terminates.
sandbox(8) manual page for additional information.
Desktop applications are expected and allowed to communicate with each other in many different ways. Applications also require access to hardware, and they expect to be able to work with the file system. Confining desktop applications using SELinux would cause many features to stop working, and some applications would be entirely unusable.
The following are examples of the ways desktop applications communicate with each other:
- X Windows -- All applications need full access to the X Server.
- File system access -- Users expect Firefox to be able to upload and download files anywhere they want on the desktop. Blocking access to any particular directory, including
.ssh/, would be difficult because of, for example, web-based SSH sessions.
- Miscellaneous -- D-Bus communications, GNOME Shell, shared memory, Kernel Keyring, access to the camera and microphone, etc.
Firefox and Chrome plug-ins are confined by SELinux, which prevents tools like
flashplugin from having access to the desktop. However, certain plug-ins require more access, which is why the following booleans are used to turn off the confinement for a subset of plug-ins:
mozilla_plugin_bind_unreserved_ports --> off mozilla_plugin_can_network_connect --> off mozilla_plugin_use_bluejeans --> off mozilla_plugin_use_gps --> off mozilla_plugin_use_spice --> off unconfined_mozilla_plugin_transition --> on
- SELinux is preventing /usr/lib64/firefox/plugin-container from 'name_bind' accesses on the tcp_socket
This solution was based on a blog post by Red Hat's Dan Walsh: 'CVE-2015-4495 and SELinux', Or why doesn't SELinux confine Firefox? (external link)
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.