In August, Mozilla was notified by security researcher Cody Crews that a malicious advertisement on a Russian news site was exploiting a vulnerability in Firefox’s PDF Viewer. The exploit payload searched for sensitive files on users’ local filesystem, and reportedly uploaded them to a server in Ukraine.
I am proud to say Firejail users were protected! The default Firejail configuration blocked access to .ssh, .gnupg and .filezilla in all directories present under /home, while more advanced configurations blocked everything else.
The main focus of Firejail project is GUI application sandboxing, with web browsers being one of the main targets. I will describe some of the new features available in Firejail, and how to use them to sandbox a web browser such as Mozilla Firefox.
A short note before we start. By default, Firefox browser uses a single process to handle multiple windows. When you start the browser, if another Firefox process is already running, the existing process opens a new tab or a new window. Make sure Firefox is not already running when you start it in Firejail sandbox.
High security browser setup
In this article, Mozilla developers try to make the case for multiple profile support in Firefox. They describe how different family members would benefit from having different bookmarks, addons, and different browsing histories, and how web developers need a different setup than QA people. With all due respect, I think we need to differentiate the profiles based on security. I would say we need a profile for accessing high security websites such as banks, and another one for everything else.
In the case of the bank we are concerned about the software running inside the browser. This software is installed as extensions or addons in Firefox, and it raises lots of privacy questions. In the words of Mozilla’s Jorge Villalobos:
Extensions that change the homepage and search settings without user consent have become very common, just like extensions that inject advertisements into Web pages or even inject malicious scripts into social media sites.
The second problem comes from inside our network. We all have these small routers connecting us to our Internet service provider. The routers are ridiculously insecure. All an attacker has to do is change the DNS setting in the router, and redirect our traffic to a fake bank website.
The solution to the first problem is to set the home directory in a partial chroot. Using –private option, Firejail mounts an empty, temporary filesystem as your home directory, basically running Firefox on factory defaults. The DNS problem is resolved using –dns option:
$ firejail --private --dns=18.104.22.168 firefox
In the example above I configure sandbox DNS to a well know server owned by Google. I do trust this server to give me the correct IP address for my bank. However, I need to mention that Google logs all your requests, and at least one national security agency has access to the data.
Everyday browser setup
For non-bank browsing, our addons and bookmarks are invaluable. The information is stored in ~/.mozilla directory, so we have to bring this directory in the partial chroot described above. We’ll also bring in ~/Downloads directory. We use it to download and upload files. As for Google DNS, it becomes a liability due to the aggressive tracking – we might be better off just using the DNS server supplied by our router!
$ firejail --whitelist=~/.mozilla --whitelist=~/Download firefox
Did you notice that every time people start a server in a container they always create a new network namespace? This is a new TCP/IP networking stack used only by their server. In the GUI world, we never use network namespaces. I don’t really know why, but the setup is pretty easy:
$ firejail --net=eth0 --whitelist=~/.mozilla --whitelist=~/Download firefox
Assuming eth0 is your main Ethernet interface, Firejail creates a new TCP/IP stack, connects it to the Ethernet network, and starts the browser as before.
To assign an IP address to the sandbox, Firejail ARP-scans the network and picks up a random address not already in use. Of course, we can be as explicit as we need to be:
$ firejail --net=eth0 --ip=192.168.1.155 [...]
or we can specify a range of IP addresses outside DHCP server scope:
$ firejail --net=eth0 --iprange=192.168.1.100,192.168.1.150 [...]
I use such an –iprange setup on my home network. Every browser/mail/BitTorrent application in the family is fighting for addresses in this range. It does require you to take a look at your router configuration, to see what addresses are covered by DHCP. If you are lazy you can go without a range, and use random addresses from across the network – DHCP servers are required to detect devices present on the network and not assign existing addresses.
Note: Ubuntu runs a local DNS server in the host network namespace. The server is not visible in the sandbox network namespace. Add –dns option to the command:
$ firejail --net=eth0 --dns=22.214.171.124 [...]
I think this is the easiest way to secure a browser. Try it out and let me know if you run into problems.