Firejail: A New Lightweight Browser And Application Sandbox
A new security/containment tool for browsers and other graphical/network applications called Firejail is available for Linux.
From the Firejail Homepage:
Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.
Written in C with virtually no dependencies, the software runs on any Linux computer with a 3.x kernel version or newer. The sandbox is lightweight, the overhead is low. There are no complicated configuration files to edit, no socket connections open, no daemons running in the background. All security features are implemented directly in Linux kernel and available on any Linux computer.
So this appears to use newer kernel features and is not dependent on systemd.
I haven’t yet used or examined this project in detail, so this is not a review or recommendation. Mostly I’m just letting you know the project exists, but it does look well-documented and organized, a good first sign. Also, contrary to some comments on the sites, I am not a developer of Firejail or associated with the project.
Similar to my Sandfox bash script, which is still running strong years later, the Firejail C program limits access to the filesystem, yet it also does much more than Sandfox by making use of Linux namespaces. For the casual user, this script may provide some nice enhancements to browser use, limiting system access of the browser process and its children.
What I and others like about approaches like this is that unlike SELinux or systemd-based methods, this method does not create a huge central point of failure (if executed well). This seems like a nice KISS (Keep It Simple, Stupid) approach.
Even if it’s not perfect, I think using a script like Firejail will improve security for most users, limiting applications and their plugins. This is becoming especially true as new browser technologies endorse web binary executables, etc.
While I haven’t reviewed this project for security, here are a few questions and points I would keep in mind during such a review:
This is an SUID program, which means its command line interface must be bullet-proof. It must only allow a limited set of actions in a limited way, and reject all bad input. Even bad parsing of characters in the command line can create a root exploit. So that is an area of code to review in any SUID program. Yet if done well, SUID programs can be secure and effective solutions, contrary to much rumor on the subject.
Also, does it drop priviledges immediately and run most of its code unpriviledged? Again, this is vital in solid SUID designs. Only the final actions that require root should have it, thus limiting exposure to complex coding errors and oversights.
It’s also important to keep in mind that this project is still maturing, which is a learning process for the developers as well. Thus it is possible to find loopholes and exploits, such as this issue raised regarding ptrace whitelisting and seccomp. The good news is that even with tailored exploits possibly available, most generic malicious code is not going to be fined-tuned to break out, so will be stopped. Consider it an enhancement at least, especially if the SUID handling is done well.
Firejail is already available in Debian Testing and for other distros, with its sources on Github. There is a related forum discussion here. I see LWN.net also featured an article on it earlier this year.
Sorry, the comment form is closed at this time.