Firejail is a GPL-2.0 SUID sandbox for Linux that wraps applications in Linux namespaces, seccomp-BPF filters, and capability restrictions with a single command. Its 900+ built-in application profiles (Firefox, VLC, etc.) and 7.3K GitHub stars make it the most accessible desktop sandboxing tool on Linux — but its SUID root requirement and documented pattern of privilege escalation CVEs make it a poor fit for AI agent sandboxing, where bubblewrap or Landlock LSM are the safer choices.
How It Works
Firejail wraps a target process using three Linux kernel primitives:
- Linux Namespaces: Creates isolated views of the network stack, process table, and mount table
- seccomp-BPF: Filters system calls (though reviewers note the default filter allows the majority of the kernel attack surface)
- Linux Capabilities: Drops unneeded privileges from the sandboxed process
It integrates with SELinux, AppArmor, and Linux cgroups, and experimental Landlock filesystem restriction support was added in 2024. No background daemon is required, and overhead is minimal. Latest release: 0.9.80 (March 2026).
Security Concerns
Firejail requires setuid root — it is a privileged SUID binary that sets up the sandbox on behalf of unprivileged users. This design has produced a recurring pattern of privilege escalation CVEs:
| CVE | CVSS | Year | Description |
|---|---|---|---|
| CVE-2020-17368 | 9.3 Critical | 2020 | Shell metacharacter injection via --output/--output-stderr flags; Firejail constructed a bash -c string without quoting, enabling arbitrary command execution |
| CVE-2022-31214 | 7.8 High | 2022 | Root escalation via crafted container join: attacker enters a namespace still in the initial user namespace with setuid binaries (su, sudo) available |
| CVE-2021-26910 | 7.0 High | 2021 | TOCTOU race condition in OverlayFS code; led to permanent removal of OverlayFS in v0.9.78 (January 2026) |
| CVE-2017-5940 | 7.2 High | 2017 | Privilege escalation via --shell argument in bandwidth command |
The project has 14 CVEs in the NVD. The structural issue: a large, complex SUID C binary that needs to trust its own inputs creates a recurring privilege escalation surface — the sandbox binary itself becomes a high-value lateral-movement target.
Comparison with Alternatives
| Tool | Root Required | Approach | Profiles | CVE History | Best For |
|---|---|---|---|---|---|
| Firejail | Yes (SUID) | Namespaces + seccomp | 900+ | Multiple escalation CVEs | Desktop app isolation |
| bubblewrap | No (user ns) | Namespaces, modular | None built-in | Minimal | AI agents, Flatpak |
| Landlock LSM | No | VFS-level kernel module | N/A | None | Filesystem restriction layer |
| nsjail | No | Namespaces + seccomp | None built-in | Minimal | CI / server workloads |
Why Assess (Not Adopt) for AI Agents
Firejail's rich profile library and single-command UX make it genuinely useful for sandboxing desktop Linux applications. For AI agent workloads specifically, however, the major agents have standardized on unprivileged approaches:
- Claude Code uses bubblewrap (Linux) / sandbox-exec (macOS) — opt-in via
/sandbox, no SUID required - OpenAI Codex uses Landlock + seccomp — kernel-level LSM, no elevated binary involved
Bubblewrap achieves the same namespace isolation as Firejail without the SUID attack surface, and is battle-tested at scale by millions of Flatpak installations. Firejail is worth assessing if you need its application profile library for desktop isolation or require Tor/VPN namespace routing, but it should not be the default choice when building agent sandboxing infrastructure.
Key Characteristics
- Version: 0.9.80 (March 2026); actively maintained, 7.3K GitHub stars
- License: GPL-2.0
- Platforms: Linux only (kernel 3.x+)
- Implementation: C (82.8%), no daemons, minimal dependencies
- Profiles: 900+ for common apps; profiles define filesystem visibility, network, and syscall policy per application