Geek Blight

I’ve blogged in the past about how I liked to run my normal web browser under a different user. In other words, I think web browsers are the weakest link in the security chain of every desktop and workstation computer. Browsers fix security issues with every release and are used to access, download and execute programs and other documents from untrusted sources, in a wide variety of formats. When I run a web browser, sometimes I don’t know what I’m going to be opening. It may be a malicious web page that will try to exploit a vulnerability in the browser I’m using. Using the method I described in the previous link, I could run the browser process as another user, so it cannot easily access my personal files, documents, cryptographic keys, etc. That method relied on running X11 and letting local users, or at least the user running the browser, connect to the server owned by my own user.

There’s a small risk involved in that but, more importantly, since moving to Wayland, the method to allow other users to access your display server is not as straighforward. In general, a solution involving Wayland means the web browser user needs access to some files in the XDG_RUNTIME_DIR directory, including the Wayland socket. I used filesystem ACLs for that and, in my experience, the process is error-prone and unreliable. Sometimes I’ve had to adjust the set of files, or the permissions I needed to grant to those files, and things have broken out of the blue after system upgrades. The second source of risk comes from the fact that, if you want that web browser to be able to play sounds, for example when watching a video, you also needed to give the web browser user access to your sound daemon. I mentioned a method to share your user’s PulseAudio instance with other users and an update on that when I switched from PulseAudio to PipeWire.

Today I wanted to share a simpler approach to all of this, which is running your web browser, typically Firefox, under a very restricted environment using Firejail. Firejail is an open source project, probably available from your package manager, that uses Linux namespaces, seccomp-bpf and capabilities to restrict what your web browser can do and access. Notably, it ships profiles for multiple applications either based on blocklists or, in the case of Firefox (the main use case), allowlists. When you run Firefox through Firejail, for example by running firejail firefox, the resulting Firefox process will be restricted in several ways and will not be able to access most of your home directory, except for the ~/Downloads directory and its own configuration and data directories. If, on top of that, it’s running under Wayland, it will not be able to spy on your screen and other windows unless there’s a second vulnerability available in the Wayland compositor.

The following screenshot shows the file manager and Firefox displaying the contents of the home directory. Firefox is running under Firejail and, as you can see, it does not display the whole directory contents. In fact, it’s not only not displaying every file, but also using custom versions of some of them inside its jail. For example, I don’t have a .bashrc file in my home directory and Firefox is seeing a “fake” one. The src directory you can see from Firefox is also completely restricted in contents and Firefox only sees one file in the whole hierarchy: my .gtkrc-2.0 configuration file because I have it stored in a “dotfiles” repository under src and symlinked to the final location.

Since I discovered Firejail, I’ve switched to using it by default when running Firefox, ditching my ad-hoc mechanisms described in previous posts.