Updated: January 1, 2016
When it comes to Linux security at home, things can be quite uneventful. So if you happen to switch from Windows to Linux, suddenly, you are left with this big gap in your sense of completeness, and you start looking for tools to relieve your unease. One such product is Firejail, a sandbox program designed to limit what processes can do.
The concept isn't new. You have SELinux, AppArmor, and Chrome, which comes with its own sandbox mechanism. The Linux kernel contains a whole bunch of cool features that help further segregate and isolate tasks from one another, and if you tap into this space, you end up with enhanced security. Or do you? Let's see what gives.
Firing up the engines
As mentioned before, Firejail is a SUID sandbox tool, intended to minimize damage caused by security breaches and exploits in your Internet-facing software. Wrap your programs with Firejail, and should they misbehave, they will be limited in what they can do.
To make itself practical, Firejail works well alongside existing hardening mechanisms, it uses control groups for additional isolation and containment, and it also utilizes a whole bunch of fancy acronyms that stand behind security technology present in modern Linux kernels. I am not listing these on purpose, because they are not relevant.
Anyhow, Firejail is not available in official repos, but you can get 32-bit and 64-bit binaries for some of the popular distros. I did my testing using Linux Mint 17.2 Rafaela. The setup was quick and nimble, I go crazy when I hear a cymbal. I installed both Firejail and its associated Firetools frontend, a GUI designed to help you manage your sandboxed applications.
Using Firejail
Firejail is a command-line tool. For the most basic usage, you simple invoke it against any which program you want, like firejail firefox. And then, the program should start in its isolated environment. Firejail reads its default sandboxing rules from the disk, which define what the application can do, including directories and files it can touch.
firejail firefox
I tried Firefox, VLC, Chromium, and several other popular programs. In all cases, the experiment went fine, although I did see a bunch of errors and warnings on the command line. Luckily, they did not cause any instability, crashes or weird behavior. In a way, this is somewhat similar to what Microsoft EMET does.
If you're wondering whether your apps are being sandboxed, you can always check the process tree for Firejail. This should give you an indication of what's running, including any special flags and options:
firejail --tree
5230:roger:firejail vlc
5231:roger:vlc
5546:roger:firejail --private firefox
5547:roger:/usr/lib/firefox/firefox
Seccomp and private mode
I decided to escalate the game a bit and try some of the Firejail options. You can enhance the default sandboxing by using the seccomp and private flags, which further isolate your applications. The former uses a whitelist filter of allowed system calls. The latter creates overlay tmpfs mounts for /dev, /home and several other filesystems, so that at no point during execution can the program touch the real data on the disk. Once the program is closed, the tmpfs mounts are removed and data discarded.
You can verify the difference between running Firefox natively and with Firejail by running lsof and inspecting its process space. First, this is what Firefox uses when executed in the standard way. The Device has a major,minor number pair of 8,9. For those not familiar with the numbering convention, this corresponds to the ninth partition on a local block (sd) device. Which is indeed where Mint is installed.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
firefox 5847 roger cwd DIR 8,9 4096 5767170 /home/r
firefox 5847 roger rtd DIR 8,9 4096 2 /
firefox 5847 roger txt REG 8,9 112848 2756216 /usr/lib/firefox/firefox
Whereas the sandboxed program using --private flag has a different set. Most notably, the current working directory corresponds to a major number 0, which stands for non-device mounts.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
firefox 5547 roger cwd DIR 0,47 220 31400 /home/r
firefox 5547 roger rtd DIR 8,9 4096 2 /
firefox 5547 roger txt REG 8,9 112848 2756216 /usr/lib/firefox/firefox
Again, this worked fine. I was able to use browsers without any noticeable lags or problems. They did launch with their own profiles, though, and not mine, which sort of makes sense. Much like the browser private/incognito modes. Moreover, browser plugins and extensions also worked without any issues.
Firetools
If you're already savvy using Firejail from command line and hammering those switches and flags like a pro, then you probably do not need any frontends. Still, they can be useful. Firetools fits the second category, even though it comes with one of the least intuitive designs ever created.
The ugly red grid block, which symbolized jail with its lines and fire with its color, can only be minimized. It's actually a sort of a shortcut panel for some of the most popular application profiles. The stats window is more useful. Yonder, you can check individual processes, shut them down, inspect memory and CPU utilization, and other fancy stuff. In that regard, Firetools acts as its own task manager for the sandboxed programs. Not bad, but it can be streamlined, and made more intuitive. The GUI is also very slow.
Under the hood
If you're keen on making your own rules and blacklists and setting up Firejail the way you like it, then you search enlightenment under /etc/firejail. Much like editing EMET XML files on your own. Be careful and patient. And remember, things may only break a year from now, long after you've forgotten about your sandboxing.
Problems
Yes, indeed, not all was golden. If you already have one of the processes running, Firejail will fail to wrap a new binary with the same name/path. Sometimes, there is a small lag when closing applications. Once, Chromium restarted rather than closed. Bogus errors included the following, without actually transforming into any kind of real issues:
VLC, [0xfeb518] pulse audio output error: cannot change volume while not playing
(vlc:1): Gtk-WARNING **: Attempting to set the permissions of `/home/roger/.local/share/recently-used.xbel', but failed: Operation not permitted
Another problem is with application profiles. If you look at the default set, you will notice that some of the programs already include special flags. For instance, VLC has seccomp, but then, there's nothing preventing you from executing the program with the desired flag from the command line.
# VLC profile
include /etc/firejail/disable-mgmt.inc
include /etc/firejail/disable-secret.inc
include /etc/firejail/disable-common.inc
include /etc/firejail/disable-history.inc
caps.drop all
seccomp
noroot
Conclusion
Firejail seems like a robustly implemented, lightweight sandbox software that closely mimics its Windows counterparts, and frankly, for no good reason. The default security in most distros is good enough never to have to worry about any big security problems. And if you do, then the logical, linear translation of the problem is to borrow concepts from the Windows world. Which is wrong, of course.
I am not sure how it really solves the non-existent security problem. I do like the approach, but it requires knowledge and tinkering, which takes away from what it's supposed to do in the first place. Still, ideology debate and effectiveness aside, if you believe you should be using a sandboxing program a-la EMET in Linux, then Firejail fits the bill. It's mostly plug-n-play, and, once properly set up, rather invisible. But it's not integrated into the repos yet, and that could cause problems down the road. Overall though, the concept has been realized quite well, and I did not have too many issues playing and testing. Firejail works as advertised, it's only the merit that's questionable. Still, if you enjoy this kind of game, then it sure will keep you happy and entertained.
Cheers.