linux

Firejail: How to Sandbox Linux Applications (2026 Guide)

Q: How do I sandbox every app automatically?

Run sudo firecfg. It creates symlinks so that any installed program with a Firejail profile is launched through Firejail automatically, whether from the terminal or your desktop menu. Run sudo firecfg --clean to reverse it.

secure-os· Updated June 25, 2026· 8 min read #linux#sandboxing#firejail#hardening

Close-up of an Ubuntu Linux terminal prompt showing a sudo command being typed

Firejail is one of the easiest ways to add a security boundary around a normal Linux application. You prefix a command with firejail, and the program runs inside a restricted environment that limits what it can see and touch on your system. If that program is later exploited — a malicious PDF, a compromised browser tab, a hostile font file — the damage is contained inside the sandbox instead of reaching the rest of your machine.

It is not a silver bullet, and it has real trade-offs that are worth understanding before you rely on it. This guide explains what Firejail actually does, how to use it day to day, where its limits are, and how it compares to Flatpak and Bubblewrap.

This sits alongside our broader explainer on Linux sandboxing and the layered approach in our Linux hardening guide.

What Firejail Actually Does

Firejail is a SUID program written in C. When you launch an application through it, it builds a restricted environment for that single process using kernel features that already exist in Linux:

Linux namespaces — give the program its own isolated view of the filesystem, network, process tree, and other resources, so it cannot see or interfere with processes outside the sandbox.
seccomp-bpf — a syscall filter that blocks the program from calling kernel system calls it has no legitimate reason to use, shrinking the kernel attack surface.
Capability dropping — strips Linux capabilities (like the ability to load kernel modules or change system time) that a desktop application never needs.
Filesystem confinement — mounts parts of the filesystem read-only, hides others entirely, and can give the app a private, empty home directory.

The key idea is least privilege: a media player or a browser should not have free access to your SSH keys, your tax documents, or your entire home directory. Firejail removes that access by default for the programs you run through it.

Macro photograph of a computer circuit board with a central processor chip — Firejail relies on kernel-level features — namespaces, seccomp syscall filtering, and capability dropping — that are built into the Linux kernel itself rather than added by separate hardware.

Installing Firejail

Firejail is packaged by most major distributions.

# Debian / Ubuntu
sudo apt install firejail firejail-profiles

# Fedora
sudo dnf install firejail

# Arch Linux
sudo pacman -S firejail

The firejail-profiles package on Debian/Ubuntu ships the large collection of pre-written security profiles — one per common application — which is where most of Firejail’s value lives. On Fedora and Arch the profiles are bundled with the main package.

To confirm it installed and see the version:

firejail --version

Basic Usage

The simplest way to run an application sandboxed is to prefix it:

firejail firefox

If Firejail ships a profile for that program (it includes hundreds — Firefox, Chromium, VLC, LibreOffice, Thunderbird, Evince, and more), it loads automatically. You will see a line in the terminal confirming which profile was applied, for example Reading profile /etc/firejail/firefox.profile.

To run a program with no profile and only the default generic restrictions:

firejail --noprofile someprogram

To give an application a brand-new, empty private home directory each time it runs — so it leaves nothing behind and sees none of your real files:

firejail --private firefox

To block all network access for a program that has no business going online:

firejail --net=none libreoffice --writer

You can inspect what is currently running inside Firejail and verify the confinement:

# List active sandboxes
firejail --list

# Show the security profile applied to a running sandbox (replace PID)
firejail --profile.print=PID

Making It Automatic With firecfg

Typing firejail before every command is tedious and easy to forget. The firecfg tool wires Firejail into your system so that supported applications are sandboxed automatically whenever you launch them — from the terminal or from your desktop menu.

sudo firecfg

This creates symbolic links in /usr/local/bin for every installed program that has a Firejail profile. After running it, launching firefox from your application menu transparently runs firejail firefox behind the scenes. To undo it:

sudo firecfg --clean

Check which programs firecfg has taken over:

firecfg --list

Customizing and Tightening Profiles

Profiles live in /etc/firejail/ as .profile files. Do not edit those directly — distribution updates will overwrite them. Instead, drop your customizations in ~/.config/firejail/ using the same filename, and Firejail will load yours in preference.

For example, to give Firefox no network access and a private downloads-only home, create ~/.config/firejail/firefox.local:

# ~/.config/firejail/firefox.local
private-bin firefox
whitelist ${HOME}/Downloads

A few of the most useful profile directives:

private — run with an empty, throwaway home directory.
whitelist <path> — make only the listed paths visible inside the sandbox; everything else in your home is hidden.
blacklist <path> — hide specific sensitive paths (e.g. ${HOME}/.ssh, ${HOME}/.gnupg).
seccomp — enable the syscall filter (on by default in most profiles).
nodbus — block D-Bus access, which is a common sandbox-escape vector.

After changing a profile, test the application carefully. Over-restricting frequently breaks features quietly (file dialogs that can’t see your files, plugins that fail to load), and a broken app tempts users to disable the sandbox entirely.

The Limitations You Must Know

Firejail improves your security posture, but it carries genuine caveats. Be honest with yourself about these.

It is SUID root. The firejail binary runs with root privileges so it can set up namespaces and mounts. That means a bug in Firejail itself is a path to privilege escalation, and Firejail has had such CVEs in its history. A complex security tool that runs as root is itself attack surface — which is precisely the criticism leveled at the SUID model.

Profiles are best-effort, not guarantees. A profile is only as good as its author made it. A poorly scoped profile, or a --noprofile launch, gives only weak confinement. The protection you get depends heavily on which profile applied and how tight it is.

It does not replace a hardened kernel or MAC. Firejail sits on top of your existing defenses. It complements — does not replace — AppArmor/SELinux, kernel hardening, and disk encryption. See our Linux hardening guide for the layers underneath it.

Distribution support varies. Because of the SUID concern, some security-focused setups prefer the alternative model below.

Firejail vs Bubblewrap vs Flatpak

These are the three sandboxing approaches you’ll encounter most on Linux.

Tool	Privilege model	Best for	Trade-off
Firejail	SUID root binary	Sandboxing any existing app via prefix or `firecfg`	Large root-privileged attack surface
Bubblewrap	Unprivileged (uses user namespaces)	The low-level engine other tools build on	No profiles of its own; you must script confinement
Flatpak	Unprivileged (built on Bubblewrap)	Sandboxed app distribution with a permissions model	Only sandboxes apps installed as Flatpaks

Bubblewrap is the unprivileged building block — it relies on user namespaces rather than a SUID binary, so it has a much smaller trusted footprint, but it is a library-like tool that doesn’t ship ready-made application profiles. Flatpak uses Bubblewrap under the hood and adds a portals-based permission system, but it only confines applications that you install through Flatpak. Firejail’s advantage is breadth: it can wrap almost any binary already on your system, including ones from your distribution’s normal repositories, with no repackaging.

A common pragmatic setup: use Flatpak (Bubblewrap-backed) where a good Flatpak exists, and reach for Firejail to confine native packages that have no sandbox of their own. For our broader comparison of isolation strategies, see Linux sandboxing, and for choosing a hardened base system, the most secure Linux distros.

FAQ

Q: Is Firejail safe to use given that it runs as root? A: For most desktop users it raises the bar against application-level exploits more than it lowers it. The honest trade-off is that the SUID firejail binary is itself root-privileged attack surface, and it has had privilege-escalation CVEs. If your threat model includes a sophisticated local attacker, the unprivileged Bubblewrap/Flatpak model is the more conservative choice. For confining a browser or a media player against hostile content, Firejail is a reasonable and effective tool.

Q: Does Firejail slow down applications? A: The overhead is small for typical desktop use. Setting up namespaces and the seccomp filter adds a brief cost at launch, and the syscall filter has negligible runtime impact for most programs. You are unlikely to notice it for browsers, office apps, or media players.

Q: How do I sandbox every app automatically? A: Run sudo firecfg. It creates symlinks so that any installed program with a Firejail profile is launched through Firejail automatically, whether from the terminal or your desktop menu. Run sudo firecfg --clean to reverse it.

Q: Will Firejail break my applications? A: It can if a profile is too restrictive — typically file-open dialogs that cannot see your files, failed plugin loads, or blocked network access. If an app misbehaves, test it with firejail --noprofile <app> to confirm the profile is the cause, then loosen the relevant directive (often a whitelist path) in ~/.config/firejail/<app>.local rather than disabling the sandbox.

Q: Is Firejail the same as a virtual machine? A: No. A VM runs a full separate kernel and is a much stronger isolation boundary. Firejail shares your host kernel and confines a single process using kernel features. It is lighter and far more convenient, but a kernel-level exploit can still cross it. For high-assurance compartmentalization, a VM-based system like Qubes OS is the appropriate tool.