Running your programs in a jail with Firejail

The Jailer

Article from Issue 173/2015

Firejail enhances security by isolating programs and processes in separate jails and thus regulating access to the filesystem.

Malware frequently exploits vulnerabilities in the browser or background services. After breaking in, malicious programs manipulate configuration files, install rootkits, or exploit other programs. A software tool called Firejail prevents malware from taking over by locking away Firefox, Apache, or any other endangered program in a jail.

In this isolated jail, which is also called a sandbox, a program that has been compromised by malware won't be able to manipulate any important files and can only run wild in the confines of its own walls. If so desired, Firejail will regulate and manage the view of the filesystem and discard any files created by the programs. Unlike a virtual machine, which emulates a complete PC, the GUI and server applications, as well as demanding games with 3D acceleration, run at full power in the Firejail sandbox.

Building a Jail

On the Firejail homepage, you can get prebuilt packages for popular distributions: Debian, Ubuntu, Linux Mint, Fedora, openSUSE, CentOS 7, and RHEL 7 [1]. All of these packages require a 64-bit system. Arch Linux users will find Firejail in the AUR; packages for Slackware are available from the SlackBuilds repository [2].

If you can't find a matching package for your distribution, you need to turn to the source code archive. After unpacking the archive, you only need to run the following command line:

./configure && make && sudo make install

For the build and installation to start, you need make, a C compiler, and the kernel headers. Firejail works with all kernels from the 3.x series; however, there are a few functions that you can only use if you have a newer kernel version (more on this subject later).

To lock an application up in jail, you need to call firejail with the name of the program you want to launch. To run Firefox in a jail, you would type:

firejail firefox

If the program you are locking away additionally needs parameters, you simply append them. If you simply call firejail without any parameters, you get a sandbox with a Bash shell, as shown in Figure 1. In contrast to what the official documentation says [3], Firejail keeps running in the background until the program in the sandbox terminates.

Figure 1: On launching, Firejail outputs an overview of the valid IP addresses in the sandbox. In this sandbox started by Firejail, the locked-in program always has a process ID of 1.

A minor stumbling hazard for web servers, databases, and other services is that their daemons immediately disappear into the background when launched. Firejail then believes that the program was terminated and takes down the sandbox and the service with it. To prevent this from happening, you need to resort to the following trick:

firejail "/etc/init.d/sshd start && sleep inf"

to keep Firejail waiting, or running, infinitely after starting the daemon.

Extremely Forgetful

The programs in the sandbox have only read access to all directories and are thus unable to manipulate any important files. However, the directories /home, /tmp, and /var remain writable (Figure 2).

Figure 2: If you launch Firejail with the additional --debug parameter in place, the tool displays a variety of information – including the mounted directories.

If these restrictions do not suit your purposes, you can enable what is known as an overlay filesystem. The technology behind this is also used on Live systems: Firejail lets the program in the sandbox think that it can manipulate the filesystem to its heart's desire. Instead, Firejail actually intercepts any changes and even discards them when the sandbox terminates. This means that your hard disk remains totally unchanged. From a technical point of view, Firejail overlays a filesystem on top of the existing one (see the "Internals" box for details).


Firejail relies on Linux kernel namespaces to create sandboxes. In doing so, Firejail tricks processes into believing that they are running entirely on their own on the system. Additionally, the tool uses namespaces to regulate access to the network and the filesystem.

Firejail also creates its own network stack in the sandbox. The sandbox thus has its own routing table, its own netfilter or iptables firewalls, and its own network interfaces. Firejail implements the overlay filesystem with the help of OverlayFS [5]. New or modified files end up in a separate filesystem, which overlays the existing filesystem. Private mode follows a similar principle: If enabled, Firejail mounts a tempfs filesystem on top of the home directory.

As the --seccomp and --caps parameters suggest, Firejail uses the kernel's seccomp support or turns to Linux Capabilities [6]. Experts can list additional syscalls after --seccomp that they want Firejail to block in the sandbox, for example:

firejail --seccomp=chmod,fchmod,fchmodat

For deeper insights into the workings of the jailed processes, try the firemon tool. It lets you monitor all of the fork, exec, ID change, and exit events in the sandbox and log these activities if needed. The firemon tool needs root privileges to do this. To discover which processes the open, unlink, mkdir, rmdir, stat, access, socket, connect, and bind functions call in glibc, try launching firejail with the --trace parameter:

firejail --trace firefox

If you want to use the overlay filesystem, simply append the --overlay option to the firejail command line:

firejail --overlay gedit

After starting Gedit in this way, you can create and modify files. After terminating Gedit, all the new files disappear into a black hole, while the modified files continue to exist unchanged on your hard disk. The overlay filesystem is useful for browsers in particular: It means that any cookies you collect, the browser history, and the cache are deleted when you terminate the browser. The --overlay option needs a Linux kernel as of version 3.18, although some distributions enabled this feature some time ago, including Ubuntu and openSUSE.


Firejail can switch the sandbox to Private mode. In this case, the sandbox hides the complete home directory specifically from the active programs. They only see empty /root and /home directories. Firejail discards any files written to these directories after terminating the sandbox. You can enable Private mode using the --private parameter:

firejail --private firefox

Instead of /root and /home, you can pass in any other directory to the sandbox. In this case, files created by the program are kept, although they will never reach the genuine /root and /home directories, but always end up in the substitute directories that you specify. In the example

firejail --private=~/junk firefox

Firefox would see the contents of the ~/junk directory as its home directory while running in the sandbox (Figure 3).

Figure 3: Firejail mounts the ~/junk directory with a single file in the sandbox. The shell running in the sandbox only sees the content of the ~/junk directory as its home.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • strace and Firejail

    Software from unknown sources always poses some risks. With the strace analysis tool and the Firejail sandbox, you can monitor and isolate unknown applications to safeguard your system.

  • SELinux Sandbox for Untrusted Programs

    The security framework SELinux is set to offer a Sandbox in which applications deemed insecure can be partitioned off from other system areas.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More