Firejail

Summary

Firejail is a lightweight Linux tool for running an application and its child processes with restricted filesystem, process, network, capability, and system-call access.

• Repository: netblue30/firejail
• Implementation: C
• License: GPL-2.0-or-later in Fedora packaging; GitHub metadata reports GPL-2.0
• Current release: 0.9.80
• Status checked: 2026-07-14

Firejail is a host process sandbox. It does not create a separate-kernel virtual machine.

Problem

Linux applications—and coding agents in particular—may read more files, open more network connections, or execute more system calls than their task requires. Giving them the full user account increases the damage from a bug, malicious dependency, or prompt injection.

Firejail narrows that access before starting the program. It is like locking unused rooms and tools before a contractor enters the house. The contractor is still inside the same building, so the building’s foundation—the host kernel—remains shared.

How It Works

• Linux namespaces: Give the process a private view of resources such as mounts, processes, users, host identity, and networking.
• Filesystem rules: Profiles can hide paths, make them read-only, expose only approved paths, create a temporary home, or build private views of /etc, /dev, /tmp, and application data.
• Seccomp-BPF: A kernel system-call filter blocks unneeded calls and reduces reachable kernel code.
• Capabilities: Linux root powers can be dropped individually or all at once.
• Network namespace: A sandbox can have no network, its own virtual interface, or filtered network access.
• Protocol filter: Profiles can limit address families such as Unix sockets, IPv4, IPv6, and netlink.
• Resource controls: Firejail integrates with Linux control groups and resource limits.
• Extra Linux security: It can work alongside SELinux or AppArmor. Experimental Landlock support adds one-way filesystem restrictions on supported kernels.
• Profile selection: Firejail chooses a profile based on the executable name. System profiles live under /etc/firejail; personal overrides can live under the user’s Firejail configuration.
• No service: It starts the sandbox directly and does not require a background daemon.

Security Boundary

• Shared kernel: The sandboxed process still uses the host Linux kernel. A kernel vulnerability reachable through allowed calls can escape the boundary.
• SUID launcher: Firejail is installed set-user-ID root so an ordinary user can create restrictions and namespaces. This design gives the launcher privileged attack surface; a flaw in Firejail itself can become a local privilege-escalation path.
• Profile-dependent safety: An omitted path, socket, capability, or network rule remains a path to the host. A permissive or incorrect profile can create a false sense of safety.
• Same user data: Without private-home or explicit filesystem rules, the process may retain access to files available to the user.
• Child containment: Restrictions apply to the launched process and its descendants.
• Defense in depth: Seccomp, capabilities, namespaces, SELinux/AppArmor, and Landlock cover different failure paths. Using several reduces risk but does not equal a VM boundary.
• Version sensitivity: Upstream supports only the latest release and development version. It warns that older versions may contain fixed security bugs and stale profiles.
• Multi-user caution: A privileged SUID sandbox is a different risk from an unprivileged per-app policy. Firejail is best treated as desktop/workstation defense in depth, not the only boundary for hostile tenants.

Platforms And Agents

• Operating system: Linux only; kernel 3.x or newer is the project’s broad baseline. Individual features need newer kernels.
• Fedora: Official Fedora packages list 0.9.80 for Fedora 42, 43, 44, Rawhide, and several EPEL releases at check time.
• Other distributions: Debian, Ubuntu, Arch, openSUSE, and others package it, but upstream warns that distribution versions may lag.
• Applications: It can launch command-line programs, graphical programs, servers, and complete login sessions.
• Coding agents: Agent-neutral. Claude Code, Codex, OpenCode, or another Linux agent can run under Firejail, but upstream does not ship an agent-specific workflow in the reviewed material.
• macOS and Windows: Not supported as host platforms because Firejail depends on Linux kernel features.

Setup

On Fedora, install the current distribution package and verify that firejail --version matches a supported upstream version.

For a coding agent:

1. Start from a custom profile rather than assuming a browser-oriented default is suitable.
2. Expose only the intended repository and required configuration paths.
3. Hide SSH keys, cloud credentials, browser state, shell history, and unrelated source trees.
4. Drop capabilities and enable a tested seccomp policy.
5. Disable networking or restrict it to the minimum practical network namespace and packet-filter rules.
6. Launch the agent by its full executable path; upstream recommends full paths to avoid nested-Firejail confusion.
7. Test package installs, builds, test suites, Git actions, and model access before trusting the profile.

firecfg can integrate shipped application profiles with desktop launchers by placing command wrappers in /usr/local/bin. That broad integration is optional and should be understood before enabling it.

Network And Credentials

• Network removal: A profile can use a private network namespace with no connectivity.
• Network filtering: Firejail can attach interfaces, set IP details, apply netfilter rules, and limit protocol families.
• No documented service brokering: Firejail does not inject GitHub, model, or cloud credentials outside the sandbox like exe.dev or Vercel Sandbox.
• No simple domain policy: Its core network controls are namespace, interface, protocol, and packet-filter based. A stable destination-name allow-list requires additional DNS/proxy design and testing.
• Filesystem secrets: Profiles can hide credential files such as SSH material and restrict the home directory.
• Environment secrets: Any token passed through the environment remains readable by the agent.
• Agent authentication: Model and Git credentials work only if their files, sockets, or environment values are exposed. Each exposure becomes part of the trusted surface.
• Safer pattern: Keep raw secrets outside the sandbox and use a narrowly scoped host or remote proxy when the workflow permits it.

Strengths

• Very low overhead: No guest operating system, VM boot, or background service.
• Fast start: Restrictions are applied as the command launches.
• Mature project: More than a decade of public development and broad Linux packaging.
• Layered controls: Filesystem, namespaces, seccomp, capabilities, protocols, SELinux/AppArmor, control groups, and experimental Landlock can work together.
• Fine-grained profiles: Users can make project-specific policies and local overrides.
• Broad program support: More than 1,300 profiles were counted by the project’s current profile statistics.
• Fedora availability: Current 0.9.80 packages are available directly through Fedora and EPEL channels.
• Open source: The privileged launcher and profile collection can be inspected and built from source.

Limits

• Weaker than a VM: It shares the host kernel and cannot contain a kernel escape the way a separate-kernel VM can.
• Privileged attack surface: SUID-root code must be kept current and trusted.
• Manual agent profile: No official coding-agent profile was found. Safe rules require local design and maintenance.
• Compatibility work: Agents install packages, spawn many tools, use Git, open sockets, and run tests. Tight policies can break these workflows in subtle ways.
• Path mistakes matter: One writable host path or credential socket can defeat much of the intended protection.
• Network policy gap: It lacks a built-in, agent-friendly hostname allow-list and credential proxy.
• Distribution lag: Upstream explicitly warns that older packaged versions can have known fixed vulnerabilities or stale profiles.
• Root inside sandbox is not VM root: Firejail can emulate or restrict root-related behavior, but it does not give the agent an independent guest kernel and full machine semantics.
• Nested infrastructure: Docker, Kubernetes, VPN, FUSE, and low-level system work may need broad permissions that weaken the profile.
• Not output validation: It limits runtime access but does not prove the agent’s code is correct or safe.

Activity And Maturity

Checked 2026-07-14:

• Repository created: 2015-08-08.
• Latest stable release: 0.9.80, published 2026-03-14.
• Development version: README lists 0.9.81.
• Latest repository push: 2026-07-14.
• Interest: 7,529 stars and 668 forks in live GitHub metadata.
• Issue load: 529 open issue/pull-request items in repository metadata, reflecting both a large project and ongoing maintenance demand.
• Fedora state: Fedora 42–44 and Rawhide listed 0.9.80 packages; EPEL availability varied by release.
• Current work: Experimental Landlock filesystem support and namespace-creation restrictions are documented in current development material.
• Assessment: Mature and actively maintained for Linux application hardening. Its age and packaging are stronger than most new agent sandboxes, but the shared-kernel and SUID design remain fundamental tradeoffs.

Best Fit

Firejail best fits a Linux or Fedora developer who:

• wants quick, local defense in depth with low memory and CPU cost;
• can design and test a project-specific profile;
• needs to protect unrelated home files from an agent;
• accepts the host kernel as part of the trusted computing base;
• keeps Firejail and its profiles current.

It is a weaker fit for malicious multi-tenant code, agents needing unrestricted root/Docker/Kubernetes behavior, macOS or Windows users, or teams requiring a separately hosted machine and simple domain/credential policies.

Comparison

• Versus Clawk: Firejail starts faster and uses fewer resources. Clawk uses a separate Linux VM, keeps guest root away from the host kernel, and provides an agent-oriented network allow-list and credential workflow. Firejail requires a custom local profile.
• Versus Bubblewrap: Both use Linux namespaces and share the kernel. Firejail supplies a SUID launcher, extensive profiles, seccomp, capabilities, and desktop integration; Bubblewrap is a smaller construction tool often used by another application or Flatpak.
• Versus Landlock: Landlock is an unprivileged, one-way filesystem restriction built into newer kernels. Firejail covers more resource types and now experiments with Landlock as another layer, but its SUID launcher adds privileged code.
• Versus Docker or devcontainers: Firejail can wrap a single host application without building an image. Containers give a packaged filesystem and service workflow but are not automatically safe when given broad mounts or a Docker socket.
• Versus Vercel Sandbox or exe.dev: Firejail is free, local, and offline-capable. Hosted VMs keep workloads away from the laptop, stay online while it sleeps, and can broker credentials. They add cloud custody and cost.
• Versus a local VM: Firejail has much lower startup and memory cost. A VM has a stronger separate-kernel boundary and more natural root/system-service behavior.

HN Context

Firejail received one direct mention in HN thread 48892859:

• Comment: polotics asked why they should switch away from running Firejail on Fedora, then acknowledged the SUID security distinction.
• Meaning: The practical comparison is not that Firejail is obsolete. It is that Clawk chooses a heavier VM boundary and agent-specific network controls, while Firejail chooses lightweight host-kernel restrictions.
• For that user: Staying with Firejail can be reasonable when its custom profile protects the required paths and the shared-kernel/SUID risk is acceptable. Switching becomes more compelling when the agent needs root, containers, broad automation, or a stronger boundary from the Fedora workstation.

No detailed profile or failure report was included in that comment, so the thread does not establish whether the user’s actual Firejail configuration is strict enough for a coding agent.

Direct Sources

• https://github.com/netblue30/firejail
• https://github.com/netblue30/firejail/blob/master/README.md
• https://github.com/netblue30/firejail/blob/master/SECURITY.md
• https://github.com/netblue30/firejail/releases/tag/0.9.80
• https://firejail.wordpress.com/features-3/
• https://firejail.wordpress.com/documentation-2/
• https://firejail.wordpress.com/download-2/release-notes/
• https://packages.fedoraproject.org/pkgs/firejail/firejail/
• https://api.github.com/repos/netblue30/firejail
• https://api.github.com/repos/netblue30/firejail/releases/latest
• https://news.ycombinator.com/item?id=48892859
• https://news.ycombinator.com/item?id=48897086

Unknowns

• Agent profile: No official Claude Code, Codex, or OpenCode profile was found.
• Independent current audit: No recent, comprehensive third-party audit report for release 0.9.80 was identified in the reviewed project material.
• Fedora configuration: Exact SELinux interaction depends on how the Fedora package was built and which profile directives are used.
• Domain filtering: A maintained reference design for hostname-based allow-lists and model/Git credential proxies was not found.
• User workload: Whether Firejail is sufficient depends on the exact files, sockets, package managers, containers, and network services an agent needs.
• Landlock readiness: Upstream labels Landlock support ongoing and experimental.
• Threat level: The project describes risk reduction, not a guarantee against a determined hostile process or kernel exploit.

Sources

• • imported AI research note for Firejail.