Firejail: an SUID sandbox for running untrusted Linux programs

The problem Firejail solves, and who it is for

Firejail is a lightweight security tool intended to protect a Linux system by setting up a restricted environment for running potentially untrusted applications. The README states it is an SUID sandbox program that reduces the risk of security breaches by using Linux namespaces, seccomp-bpf and Linux capabilities. 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 and mount table.

The target user is someone running mainstream desktop software on a general-purpose Linux machine. The repository ships sandbox profiles for a number of more common Linux programs, such as Mozilla Firefox, Chromium, VLC and Transmission, and the Makefile confirms the profile layout: PROFILES_PRO is built from etc/profile*/*.profile, with shared fragments under etc/inc/*.inc and network definitions under etc/net/*.net. The README also claims it can sandbox any type of processes: servers, graphical applications, and even user login sessions. That last claim is the ambitious one. Sandboxing a login session means the whole session inherits the namespace restrictions, and any profile mistake follows the user everywhere rather than being confined to one application.

How the namespaces, seccomp filters and profiles fit together

The mechanism is kernel-level, not userspace-level. Firejail is written in C with virtually no dependencies, and the README says 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 with a 3.x kernel version or newer. That is a real architectural difference from tools that install a supervisor process or a long-running service.

The seccomp side is compiled into the build. The Makefile lists SECCOMP_FILTERS as seccomp, seccomp.debug, seccomp.32, seccomp.block_secondary, seccomp.mdwx, seccomp.mdwx.32, seccomp.namespaces and seccomp.namespaces.32, so there are separate filter variants for 64-bit and 32-bit execution, plus narrower filters such as block_secondary and the mdwx set. The build also produces helper binaries rather than one monolithic command: APPS includes firecfg, firejail, firemon, profstats, jailcheck, etc-cleanup and fbwrap, while SBOX_APPS covers fbuilder and ftee, and SBOX_APPS_NON_DUMPABLE covers fcopy, fldd, fnet, fnetfilter, fzenity, fsec-optimize, fsec-print, fseccomp, fnettrace, fnettrace-dns, fnettrace-sni, fnettrace-icmp and fnetlock. Those names tell you what the project expects you to do: inspect filters, trace DNS and SNI lookups, and lock down networking.

Profiles are text files, not code. A .profile under etc/profile*/*.profile pulls in shared .inc fragments and can reference a .net file for network policy. Firejail can work in an SELinux or AppArmor environment, and it is integrated with Linux Control Groups, so the sandbox does not have to replace an existing mandatory access control setup.

Installing Firejail on Debian and Ubuntu

The README is blunt about distribution packages. For Debian it notes that versions from Debian stable and backports are likely to be outdated, and recommends either downloading and installing the .deb package from the latest release or building from source. For Ubuntu the same warning appears, with an additional reason: the README says the firejail package for Ubuntu 20.04 has been left vulnerable to CVE-2021-26910 for months after a patch for it was posted on Launchpad. The README also reproduces the Ubuntu wiki's own explanation that binary packages in universe and multiverse are supported by the Ubuntu community rather than the Ubuntu Security team, and firejail lives in universe.

The old PPA instructions are still in the README inside a collapsed section, and they show the shape of the install:

sudo add-apt-repository ppa:deki/firejail
sudo apt-get update
sudo apt-get install firejail firejail-profiles

Note that the README labels this as old instructions and now points at the .deb from the latest release instead. The repository layout is what you would expect for a C project that builds with autotools: configure, configure.ac, config.mk.in, config.sh.in and a top-level Makefile. The Makefile begins with -include config.mk, so a build produces config.mk and the main Makefile picks it up. Building from source means running configure and then make against that generated config.mk; the README points to a building section for the details rather than inlining them.

A first real use: sandboxing a browser

The README's own quick start is a video, so the practical entry point is the profile set and the firejail command. The repository ships profiles for Firefox, Chromium, VLC and Transmission among others, and the Makefile confirms the naming convention is <name>.profile under etc/profile*/. The documented usage pattern is to prefix the program with firejail rather than to change how the program starts.

firejail firefox

What you should see is the same browser window, but the process tree and its descendants run inside the sandbox. The README describes the effect as a private view of the network stack, process table and mount table. For a desktop user the visible difference is usually in what the application can reach on disk and on the network, not in the window itself.

If you want to inspect what a profile actually applies instead of trusting it, the build produces fsec-print and fsec-optimize, along with fseccomp. Those are the tools to reach for when a profile needs auditing. firemon is the monitoring binary, and jailcheck exists to check running sandboxes. The README does not document the exact flags for these helpers, so read the man pages rather than guessing; the Makefile shows MANPAGES1_IN and MANPAGES5_IN are generated from src/man/*.1.in and src/man/*.5.in.

For a system-wide setup, firecfg is the binary that manages desktop integration. The README does not spell out its behaviour, so treat the man page as the source of truth before running it.

The SUID design is the biggest trade-off

Firejail is an SUID sandbox. That single word carries most of the risk discussion around the project, and the README does not hide it. An SUID binary runs with elevated privileges, which means the sandboxing code itself becomes part of your attack surface; a flaw in Firejail is more serious than a flaw in an unprivileged wrapper. The project maintains a SECURITY.md and the README points to it twice, once for vulnerabilities and once for supported versions. That is the right place to look, and the fact that the README recommends the latest release .deb over distribution packages is a direct consequence of the model: you are depending on a privileged component, so patch latency matters more than it does for an ordinary application.

The second limitation is scope. Firejail is Linux only. The README's kernel requirement is a 3.x kernel or newer, and nothing in the repository suggests a port to another operating system. Anyone searching for a Windows or macOS build will not find one here.

The third is the profile problem. Profiles are contributions, and the Makefile's PROFILES_PRO wildcard shows they are plain files in the tree. A profile that is too permissive gives a false sense of safety; one that is too strict breaks the application. The project ships fsec-print and fsec-optimize precisely because profile correctness is not automatic. If your application is not covered by an existing profile, you are writing your own, and the README does not walk you through that.

Firejail compared with Bubblewrap and Docker

The most common comparison is with Bubblewrap, and the difference is in who holds privilege. Bubblewrap is designed as an unprivileged sandbox that relies on user namespaces; Firejail is an SUID program. That means Firejail can set up restrictions that an unprivileged process cannot, and it also means Firejail carries a privileged binary on the system. The README lists no dependencies and no daemons, so the operational footprint is small either way, but the trust model is not the same. If your threat model treats a local privilege escalation in the sandbox tool as unacceptable, the SUID design is the deciding factor against Firejail.

Docker is a different category. Firejail confines a process on the host it already runs on, with the host's filesystem visible through whatever the profile allows. Docker builds an image, ships it, and runs it in a container with its own filesystem. For running a distribution packager's build or a service with a pinned environment, Docker's model fits better. For confining the browser you already have installed, Firejail's model fits better because there is no image to build and no registry involved.

Firejail does sit next to AppArmor and SELinux rather than replacing them. The README states it can work in an SELinux or AppArmor environment and is integrated with Linux Control Groups. If you already run a mandatory access control policy, Firejail adds per-process namespace isolation on top rather than asking you to tear the policy down.

Maintenance, releases and the GPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-20. Recent releases are 0.9.80 on 2026-03-14, 0.9.78 on 2026-01-21 and 0.9.76 on 2025-07-30. The cadence is steady but not fast, and the README's own advice to prefer the latest release .deb over distribution packages means upgrade work falls on you rather than on your package manager. On Debian and Ubuntu that is a manual .deb install each time, unless you build from source.

Building from source has its own recurring cost. The tree uses autotools: configure, configure.ac, config.mk.in, config.sh.in and a generated config.mk consumed by the Makefile. The Makefile also expects a set of tools that are configurable through config.mk, including CC, CPPCHECK, GAWK, SCAN_BUILD and STRIP, and it runs codespell. A source build therefore needs more than a C compiler if you want the full target set, and the CI configuration under ci/ and .gitlab-ci.yml shows the project runs several build variants of its own.

Firejail is GPL-2.0. If you redistribute it or a modified version, the licence terms apply to that distribution. The profiles and helper binaries ship in the same tree, so there is no separate licence to reconcile for them. This is a description of the licence identifier in the repository, not legal advice; if you plan to bundle Firejail in a product, have someone qualified read COPYING.

Editorial conclusion

Adopt Firejail if you want per-application confinement on a Linux desktop or server and you are willing to install from the latest release rather than a stale distribution package. Do not adopt it if you need a sandbox that runs unprivileged, or if your target is Windows or macOS, which the project does not support. Before rolling it out, read SECURITY.md for the supported versions, check the release page for the newest .deb, and verify that the profiles you depend on exist under etc/profile* in the repository.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. netblue30/firejail on GitHub
3. Project website
4. README
5. Releases