Running your programs in a jail with Firejail

Mount Miracles

In all of the configurations I've looked at thus far, the programs in the sandbox see a few, or many, files from your filesystem. But you can change this, too, by mounting a completely different Linux installation in the sandbox. The filesystem can reside on the second partition, or you can install a completely new Linux system in a separate directory. Various tools are available for doing this; on Debian, for example, you could use debootstrap (Figures 4 and 5). When you are done, you only need to tell Firejail the name of the subdirectory:

firejail --chroot=/debian iceweasel --name=debian
Figure 4: These two commands quickly create a new Debian installation in the /debian subdirectory, which can then …

This command would mount the /debian directory as the root filesystem in the sandbox and then launch Iceweasel. The browser thus only sees the files and directories below /debian. If you launch the sandbox as a normal user, unlike in Figure 4, the program in the sandbox will run under this user ID (UID). The UIDs on your system and the one used in the sandbox need to match in this case. Finally, the --name= option changes the hostname. In this example, Iceweasel would think it was running on a computer by the name of debian.

Figure 5: … be foisted onto a sandbox.


If you specify the additional --seccomp option, Firejail prevents programs in the sandbox from performing a couple of security-critical actions. Among other things, they are not allowed to load kernel modules, manage swap memory, run programs with root privileges (SUID), or restart the system. If an application tries to call one of these system functions, the kernel immediately terminates it. This totally useful safety net is only available as of the Linux kernel version 3.5, however.

Additionally, Firejail supports the --caps parameter. Firejail uses it to enable a security filter kernel-side. Among other things, the filter blocks any attempts to restart the system, replace the kernel, load kernel modules, escalate privileges of the processes in the sandbox (using the nice value), or assign system administrator privileges to them. The --seccomp and --caps options thus partly prevent the same actions. In the case of --caps, however, the kernel does not terminate the process but lets it continue running. This security filter also supports older Linux kernels.

On the Network

If desired, Firejail can integrate its own TCP/IP network interface into the sandbox. You can then connect to this with an existing network bridge, which is useful for test purposes or to set up a demilitarized zone (DMZ). The following command:

firejail --net=br0 --ip= firefox

tells Firejail to connect the network bridge that already exists on the PC, br0, with the sandbox in which Firefox is running. If you leave out the --ip parameter, Firejail will try to find a matching free IP address itself (as shown in Figure 6). Specifying the --net=none parameter completely disconnects the sandbox from the network.

Figure 6: In this example, a network bridge was first set up (br0); then, the sandbox was connected to it. Finally, Firejail assigned itself an IP address that was not previously used.

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

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