Sandboxing

Firejail runs applications inside lightweight sandboxes using Linux namespaces, seccomp syscall filters, capability dropping, filesystem whitelists/blacklists, and optional network isolation.

Athena OS ships Firejail preinstalled. This page explains when Firejail is the right tool, when AppArmor profiles are more appropriate, and how to use both without accidentally weakening the security of applications that already have strong internal sandboxing.

When to use Firejail

Firejail is a wrapper sandbox - it applies isolation around a process from the outside. This makes it effective in specific situations and ineffective in others. Knowing the difference matters.

Use Firejail for:

• Document viewers and file parsers - evince, libreoffice, zathura, media players. These have no internal sandboxing and regularly parse untrusted content.
• Unknown binaries - executables from client systems, CTF challenges, or unverified sources.
• Legacy or simple CLI tools - tools with no built-in privilege separation that touch untrusted input.
• Containing opportunistic threats - mass-targeting malware, scripts that rely on filesystem access rather than kernel exploits.

Do not use Firejail as the primary sandbox for browsers:

Modern browsers (Firefox, Chromium) implement a broker-architecture sandbox that isolates every renderer process individually - a far stronger model than what any wrapper sandbox can provide. Wrapping Firefox in Firejail puts a weak outer perimeter around a much stronger inner one. More critically, if Firejail’s seccomp profile blocks syscalls that Firefox needs to build its own internal sandbox, you end up with worse security than running Firefox normally.

Never run a browser with --no-sandbox or equivalent options to satisfy Firejail’s requirements. Use AppArmor enforce instead - see AppArmor integration below.

The SUID tradeoff:

Firejail is a SUID binary. It temporarily holds elevated privileges to set up the sandbox. This means Firejail itself is an attack surface - 18 CVEs in its history are directly attributable to this design, most involving privilege escalation. This does not make Firejail useless, but it means it is not a zero-cost addition. For applications you run constantly (browsers, email), AppArmor profiles are a better choice: same filesystem isolation, no SUID surface.

What Firejail does not protect against:

A sophisticated attacker with a kernel exploit and full code execution inside the sandbox can escape from the majority of Firejail profiles. Firejail is not a mitigation against targeted kernel-level attacks. It protects against opportunistic threats and limits blast radius - that is genuinely useful, but it is not the same as strong isolation.

Quick usage patterns

Run any app sandboxed:

firejail <program> [args...]

Isolate an app from your real HOME (ephemeral):

firejail --private firefox

Allow only a couple of folders:

firejail --private --whitelist=$HOME/Downloads --whitelist=$HOME/burp-projects burpsuite

No network:

firejail --net=none evince sample.pdf

Ephemeral writes (discard on exit):

firejail --overlay firefox

Drop dangerous capabilities and enable seccomp:

firejail --caps.drop=all --seccomp <program>

Bind to a specific interface (e.g., keep scans off your management NIC):

firejail --net=eth1 nmap -sS -Pn 10.10.0.0/24

List sandboxes / debug:

firejail --list
firejail --debug --trace=all <program>

Profiles

Firejail uses per-app profiles to standardize restrictions.

• System profiles live in /etc/firejail/*.profile
• User overrides: ~/.config/firejail/*.profile

Example: Firefox

Firefox has strong internal sandboxing. Use AppArmor rather than Firejail to avoid interfering with it:

# Enforce the upstream Firefox AppArmor profile
sudo aa-enforce /etc/apparmor.d/firefox

# Or use the apparmor.d project profile for more complete coverage
yay -S apparmor.d
sudo aa-enforce /etc/apparmor.d/firefox

If you need additional filesystem restrictions beyond what the profile provides, add a local override in /etc/apparmor.d/local/firefox rather than wrapping with Firejail.

Example: Burp Suite

In this example: workspace-only, persistent projects.

Create /etc/firejail/burpsuite.athena.profile:

private
whitelist ${HOME}/burp-projects
read-only /usr
read-only /etc
caps.drop all
seccomp
netfilter

Run:

firejail --profile=/etc/firejail/burpsuite.athena.profile burpsuite
# or: firejail --profile=... java -jar /opt/burpsuite/burpsuite.jar

Example: Wireshark

Packet capture requires raw sockets. Use capabilities on dumpcap and keep the GUI confined:

# one-time capability grant (already handled on Athena in most cases)
sudo setcap cap_net_raw,cap_net_admin+ep /usr/bin/dumpcap

Create /etc/firejail/wireshark.athena.profile:

noblacklist ${HOME}/.wireshark
read-only /usr
read-only /etc
caps.drop all
seccomp
net host      # capture host interfaces

Run:

firejail --profile=/etc/firejail/wireshark.athena.profile wireshark

Note

For wireless injection or custom drivers, prefer a disposable VM. Firejail won’t grant kernel-module magic that the OS denies.

AppArmor integration

Using Firejail integrated with AppArmor yields defense-in-depth:

• Firejail: runtime isolation (namespaces, seccomp, caps, private FS, network).
• AppArmor: kernel-enforced path rules (what files/sockets the app can touch).

What this mix mitigates better than either alone

• Escape attempts from a compromised app: AppArmor blocks access to sensitive paths; Firejail blocks dangerous syscalls and caps.
• Credential theft & data exfiltration: AppArmor denies ~/.ssh, ~/.gnupg, etc.; Firejail’s —private/whitelists hide most of $HOME.
• Network-pivot risks: Firejail can disable or fence off networking per-app; AppArmor can still restrict IPC and filesystem escape tricks.
• X11 abuse: Prefer Wayland; otherwise, combine Firejail’s X filters with AppArmor to limit file fallout if X leaks keystrokes/window grabs.

Practical pattern on Athena:

• Browsers → AppArmor enforce only (do not wrap with Firejail - it can weaken the browser’s internal sandbox)
• PDF viewers, media players, document editors → Firejail + AppArmor enforce
• New/unknown CLI tools → Firejail with --private and minimal whitelists + AppArmor in complain while you learn, then enforce if stable
• Unknown binaries → Firejail --net=none --private --caps.drop=all or a VM for anything high-risk

Browsers

Firefox and Chromium implement multi-process sandboxing internally. Every tab renderer runs in a restricted child process with minimal capabilities and a tight seccomp filter. This is a broker-architecture sandbox - the browser coordinates dangerous operations through a privileged parent, and the child processes that parse untrusted content get almost nothing.

Wrapping this in Firejail does not add meaningfully to this protection. What it can do is break it: if Firejail’s seccomp profile blocks unshare, clone, or other syscalls that Firefox needs to create its renderer sandboxes, you get a browser that runs with weaker internal isolation.

The correct approach is an AppArmor profile that enforces filesystem boundaries without interfering with the browser’s internal process model. The apparmor.d project maintains well-tested profiles:

# Install apparmor.d
sudo pacman -S apparmor.d-git

# Enforce the Firefox profile
sudo aa-enforce /etc/apparmor.d/firefox

# Verify it is enforcing
aa-status | grep firefox

The apparmor.d Firefox profile also supports the AppArmor userns feature, which restricts user namespace creation to confined processes - preserving Firefox’s ability to build its own sandbox while preventing an escaped renderer from creating new namespaces.

Working with files safely

• “Open suspicious file”: Put into a dedicated ~/Samples folder and open with:

  firejail --net=none --private --whitelist=$HOME/Samples evince ~/Samples/suspicious.pdf

  The viewer sees only Samples, has no network, and can’t write outside.
• Browser downloads: Restrict the browser to ~/Downloads and move files to a lab VM if they require execution.

Network isolation tips

• No surprises: —net=none for tools that never need internet (document viewers).
• Controlled egress: —netfilter applies a per-sandbox filter (nft/iptables).
• Dedicated interface: Pin scans to an attack NIC (—net=eth1) so they don’t leak over Wi-Fi.

Wayland vs X11

• Prefer Wayland for sandboxed GUI apps: it reduces classic X11 input/screen snooping.
• If you must use X11, Firejail offers —x11 and even nested servers (Xephyr). Combine with AppArmor to protect files if X is abused.

Troubleshooting

App won’t see files → you’re probably using —private. Add precise whitelists:

firejail --private --whitelist=$HOME/Downloads <app>

• Network missing → remove —net=none or specify the right interface.
• Weird Java/Electron issues → add specific runtime whitelists for their config folders, then iterate.