Sandboxing [1], or isolating processes and applications in their own environment, is a long-established practice in Linux. Unfortunately, although it is efficient, it can be difficult to configure and use. Even containers and virtual machines have not improved the process much, because they are only as secure as their configuration. What makes Firejail [2] so different is that it makes sandboxing easy and can do far more if you are willing to learn how to configure it. This simplicity has made Firejail the center of attention in less than a year.

Firejail is a structural security solution; it is configured to prevent intrusions rather than react to them the way an antivirus program does. Instead of adding daemons and other applications, it works by creating a restricted environment with its own set of solutions, running within user space and using features that are already a part of the Linux kernel, such as seccomp-bpf [3]. The result is sandboxing that requires far fewer system resources than traditional solutions, such as creating a chroot jail [4], and is easy to customize.

In fact, Firejail installs with 64 security profiles for popular applications, ranging from Firefox and KMail to XChat and Wine, as well as a generic profile used automatically for applications and processes that lack a custom profile (Figure 1). All profiles use a basic syntax with one item per line that can easily be learned by studying the profiles that are installed along with the command (Figure 2).

Figure 1: Firejail ships with security profiles for common Linux applications, plus a default profile for anything else.

Figure 2: Instead of using command-line options, you can create custom profiles, with one option per line. You can study the pre-defined profiles to learn how to create your own.

At the most basic level, running Firejail could not be simpler. Running the command by itself opens a sandbox of the default shell. To run an application in a sandbox, simply preface the command, using the following standard structure:

firejail COMMAND COMMAND-OPTIONS

However, you can add options to Firejail to configure the command's environment more concisely. If you constantly use the same options, you might prefer to customize the command's security profiles or to create your own profiles. For some purposes, you might even want to maintain multiple profiles of the same command, specifying the one to use with --profile=FILENAME.

Configuring Sandboxes

The default options for running Firejail go far beyond those commonly used by other commands, such as setting the location of the sandbox's logfile with --output=LOGFILE. Many of Firejail's options show their relation to one another by beginning with the same prefix, a custom that simplifies learning about them.

To start, the protection afforded by a security file can be enhanced by using --blacklist= and --white-list= to define directories or files that cannot or can be accessed from within the sandbox. Alternatively, blacklisted or whitelisted directories or files can be listed in the profile, each item given on a separate line starting with blacklist or whitelist.

Other standard behavior can be modified with options. For instance, -c closes the sandbox as soon as the command is run once, making it an approximate equivalent of sudo. Similarly, --chroot=DIRECTORY creates a traditional chroot jail that runs from its own root directory, and --ignore=COMMAND cancels the use of one command listed in an existing profile and -- COMMAND (with no option letter) skips a command listed in the profile. Although a Bash shell is assumed, you can also specify another shell with --csh, --zsh, or --shell=SHELL. Sandboxed environments can similarly be defined with --env=NAME=VALUE.

Still other options can define how a sandbox is used. For example, --noroot runs the sandbox with no root user, limiting what you or any intruder can use it for. The --read-only=DIRECTORY OR FILE option also restricts what files can be accessed from the sandbox. By contrast, --write-etc and --write-var give access to key administration files within the sandbox. Another option is to define who can use the sandbox by specifying --user=USER.

Because a sandbox is isolated from the main system, its networking capabilities can be defined separately. Firejail includes a host of options, such as --ip=ADDRESS, --hostname-NAME, --dns=ADDRESS, and --net=ETHERNET, all of which can be configured separately from the main system. Other related options can be identified by their prefix, so that IP addresses, for example, can also be defined by --ip=NONE and --ipv6=NAME. These options are too numerous to detail, so consult Firejail's lengthy man pages for more information.

A sandbox can also be limited by the maximum file size that a process can create using --rlimit-fsize=NUMBER or by the maximum number of files that can be opened by a process with --rlimit-nofile=NUMBER. Processes can also be limited by the maximum number of processes a user can open with --rlimit-nproc=NUMBER.

Ordinarily, by definition, a sandbox has no communication with the system's main directory structure. After all, that is what makes a sandbox secure. However, you view directories and files with --ls=PID OR NAME or --get= PID OR NAME. Additionally, you can read a list of top processes within sandboxes with --top, or you can view all sandboxed processes using --list or a hierarchical view using --tree (Figure 3). Another option is to overlay the present working directory with the sandbox so that the two can be read as a single directory, using --overlay or --overlay-tmpfs.

Figure 3: Viewing processes in list and tree views.

If you are using Firejail for more than a quick security feature, you might also want to use --name=NAME to make the sandbox you create easier to identify or for keeping track of multiple sandboxes. If nothing else, a named sandbox can be easily closed by adding the option --shutdown=NAME.

Improving Security Even More

For many users, these options are more than enough to make use of Firejail. However, you can improve the security of Firejail with some advanced options.

One option is to manipulate Linux Capabilities, a kernel feature that divides root privileges into as many as three dozen functions. For example, CAP_SYS_MODULE lets you load modules from anywhere, instead of restricting the search path to /lib/modules, whereas CAP_SYS_BOOT enables rebooting, and CAP_SYS_NICE lets you change the priority of processes and threads. Using Linux Capabilities, you can increase the security of a sandbox by limiting what the root user can do in the sandbox. With --caps.keep=CAPABILITY, CAPABILITY, you can specify the capabilities that can be used within the sandbox; conversely, with caps.drop=CAPABILITY, CAPABILITY, you can prevent the listed capabilities from being used in the sandbox. You could even ban all capabilities altogether with --caps.drop=all, although --noroot would work just as well.

Another set of options that begins with private separates the sandbox even further from the main system by creating a temporary filesystem that lasts only until the sandbox shuts down. Each of these options creates a particular directory:

• --private=DIRECTORY creates a user's home directory.
• --private-bin= FILE, FILE creates the /bin directory, adding applications in a comma-separated list.
• --private-dev creates a limited /dev directory.
• --private-etc=FILES, DIRECTORIES creates the sandbox's /etc directory, adding applications in a comma-separated list.
• --private-tmp mounts an empty temporary filesystem on top of /tmp, so that the two directories display together.

As often as not, you would want to use these options together, so you might prefer to create a private profile rather than adding all these options separately.

A third set of options manipulates seccomp [5], the kernel function that controls application sandboxing. Firejail's man page includes almost 50 system calls, including mount, swapon and swapoff, and reboot. Using --seccomp=SYSTEMCALL, SYSTEMCALL enables the sandbox system calls, whereas --seccomp.drop=SYSTEMCALL, SYSTEMCALL specifically disables system calls.

Running Firejail

Firejail is also available as a desktop application called Firetools (Figure 4). However, Firetools has no advantage over the carefully named options of Firejail, except possibly to divide them up into small chunks of information. I admit that I personally find it confusing compared with the Firejail man page.

Figure 4: Firejail runs on the desktop as Firetools, but the advantage over the command line is minimal.

Still, no matter how you access these options, Firejail remains a powerful new weapon in the security toolbox. Thanks to the ready-made profiles, it is simple enough to begin using without reading the documentation, except their example. Yet, thanks to the broad range of options and the lower overhead, it is as useful for the sys admins of corporate networks as for a lone user on a workstation.

If you wanted, you could use Firejail for every application. However, your web browser, email reader, and chat applications are probably mostly what you need to sandbox. A convenient way to set them up is to use launchers on the panel or desktop, because the launchers can store a complicated command structure.