Linux Application Sandboxing with Bubblewrap, Firejail and Flatpak

A Basilisk researcher opened a bug bounty PDF in Evince and thirty seconds later auditd logged a read attempt against ~/.ssh/id_ed25519. The process had zero legitimate reason to touch that directory, yet it tried. That incident, which ended fine because Evince was running inside a restrictive Bubblewrap profile, is why this post exists. Desktop Linux sandboxing is not security theater: it is the layer that separates an annoying exploit from a quiet exfiltration of SSH keys, cloud tokens and session cookies. Lets land Bubblewrap, Firejail and Flatpak with profiles battle-tested in production OPSEC for Security Researchers: Building a Personal Threat Model.

Why the desktop is the real target

Servers get hardened, the desktop gets forgotten, yet the valuable things live exactly there: SSH keys, browser sessions, cloud tokens, saved passwords and client data. A single renderer exploit in a browser, PDF reader or office suite is enough to run with your user privileges. Without a sandbox, 'with user privileges' means full access to your entire $HOME. The goal of sandboxing is not to prevent every exploit but to shrink the radius of a successful one until it reaches nothing worth having.

The mechanism underneath is Linux namespaces and seccomp filters, which tell the kernel which files, networks, processes and syscalls a process may even see. Bubblewrap, Firejail and Flatpak are three levels of convenience over the same kernel primitives. Understand the primitives and you configure all three on purpose instead of by copy-paste. The most common misconception is treating sandboxing as all-or-nothing; in reality it is a dial, and every access you revoke, every syscall you block, every permission you strip moves the dial measurably in your favor even if you never reach the theoretical maximum.

Bubblewrap: the foundation

Bubblewrap (bwrap) is the foundation. It is the unprivileged container runtime Flatpak uses under the hood, maintained by the containers project and auditable in a few hundred lines of C. A minimal profile to open PDFs looks like: bwrap --ro-bind /usr /usr --ro-bind /etc /etc --proc /proc --dev /dev --tmpfs /tmp --bind ~/Downloads/sandbox-pdf /home/user --unshare-all --share-net /usr/bin/zathura file.pdf. Note --unshare-all followed by --share-net only if required, and the bind of a specific folder instead of full $HOME. That allow-list pattern is what separates real sandboxing from placebo, and it pairs well with DFIR investigations DFIR on Linux: Live Triage with UAC and Velociraptor.

The decisive point is the default-deny posture: you bind in exactly what the process needs, and everything else does not exist for it. A PDF reader needs no network, so drop --share-net; it does not need ~/.ssh, so that path never appears in the bound tree. Every bind you leave out is a door the exploit never even sees.

Firejail: ready profiles for everyday use

Firejail sits at a higher level and ships roughly 1,000 ready profiles under /etc/firejail. For daily researcher workstation use, the trio firefox.profile, thunderbird.profile and libreoffice.profile covers 80 percent of the attack surface. Start with firejail --profile=/etc/firejail/firefox.profile --private-tmp --dns=9.9.9.9 firefox. Enable AppArmor with firejail --apparmor and inspect status via firejail --list. Firejails historical Achilles heel is the SUID binary; if that bothers you, install with setcap cap_sys_admin+ep on recent kernels or migrate to plain Bubblewrap. To open suspected phishing docs, combine it with metadata hygiene before any forwarding Metadata Hygiene: Stripping EXIF, PDF and Office Before You Publish.

Firejail is the fastest path to meaningful security because the profiles already exist and are maintained. The price is the SUID binary, which is itself part of the attack surface. For most researchers the trade-off is acceptable; for the hardest threat models, plain Bubblewrap without SUID wins.

Flatpak: declarative permissions and Flatseal

Flatpak ships apps with a declarative permission manifest. The command worth memorizing is flatpak override --user --nofilesystem=home org.mozilla.firefox followed by flatpak override --user --filesystem=~/Downloads org.mozilla.firefox. That revokes full $HOME access and returns only Downloads. To audit what each app asks for, run flatpak info --show-permissions org.telegram.desktop or open Flatseal. Apps like Zoom, Slack and Discord running via Flatpak with --nofilesystem=host and --nodevice=all drastically cut the blast radius of a rendering CVE. It plugs straight into hardening high-risk workstations Linux Server Hardening: Applying CIS Benchmark Without Breaking Production.

The most common mistake is trusting Flatpak alone to be secure. Many apps ship with broad default permissions like filesystem=home or talk-name=org.freedesktop.Flatpak, which effectively dissolves the sandbox. Review every installed app once with Flatseal and systematically revoke what it does not need; the manifest is the developer's offer, not a security guarantee.

Real-world scenarios at Basilisk

Real-world scenarios we run at Basilisk: analysis of client-supplied samples lives in a dedicated Remnux VM, not desktop sandbox Malware Analysis in an Isolated Lab: Safe Setup with FlareVM and REMnux. But reading report PDFs, opening client docx, browsing bug bounty sites and testing a browser extension all happen inside Bubblewrap profiles with a separate network namespace via slirp4netns. For clients that mandate Signal Desktop, we run the Flatpak build with --nofilesystem=home --filesystem=xdg-download and pass a hardware token via --device=all only during pairing Comms OPSEC: Signal, SimpleX and Session Technically Compared. Every profile lives in git, reviewed in pull requests, exactly like production code.

The line between sandbox and VM is a line of threat. Untrusted code that will actually execute belongs in a throwaway VM with its own kernel boundary. Trusted apps that render potentially hostile input belong in a desktop sandbox. Mixing the two means either opening a malware sample on your desktop or inflating every PDF click into a full VM.

Namespaces and seccomp: what protects under the hood

Under all three tools lie the same kernel primitives. User, mount, PID, network and IPC namespaces isolate what the process sees of the system and other processes. seccomp-bpf filters the allowed syscalls and thereby shrinks the kernel attack surface an escape could even ride on. A tight seccomp profile is the difference between a renderer bug that dies in the sandbox and one that breaks out through an exotic syscall chain.

You do not need to write filters by hand, but you should understand that --unshare-all sets the namespaces and that Firejail and Flatpak ship sensible seccomp defaults. When an app breaks, diagnose with strace which syscall or path is missing and open just that one, instead of loosening the sandbox wholesale.

Three common pitfalls

Three common pitfalls. First: skipping --unshare-user-try or --unshare-net because the app complains, leaving you with paper sandboxing. Fix it by isolating first with --share-net then tightening, monitoring with strace -f -e network. Second: trusting Flatpak alone to protect against escape via a misconfigured D-Bus portal; review portals with flatpak permissions. Third: leaving the microphone open. Apply flatpak override --nodevice=all globally and grant case by case.

For continuous verification, wire profiles into Sigma rules that catch escape attempts Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule and review quarterly, because manifests drift every update cycle. A sandbox that was tight six months ago can be wide open after three app updates without anyone noticing.

Quick-start checklist in five steps

Step one: set flatpak override --user --nofilesystem=home globally and then return only the needed folders per app. Step two: replace the default PDF reader with a Bubblewrap wrapper bound exclusively to ~/Downloads and running without --share-net. Step three: launch browser, mail client and office through Firejail with AppArmor enabled. Step four: block microphone and camera globally with --nodevice=all and grant them only case by case. Step five: version every wrapper and override in a private git repo so the config is reviewable and reproducible.

Treat this list as a living document. Every newly installed app goes through the same filter before it first processes hostile input: check the manifest, revoke $HOME, network only on demand, devices locked. After two weeks the procedure becomes reflex, the effort per new app drops below five minutes, and the attack surface stays permanently small instead of quietly creeping back up.

FAQ: Bubblewrap, Firejail or Flatpak, which should I use?

Use all three for different jobs. Flatpak for installed GUI apps whose permissions you trim with Flatseal. Firejail for quick, maintained profiles of known programs like Firefox and LibreOffice. Bubblewrap for tailor-made wrappers with a strict allow-list, such as your PDF reader bound only to ~/Downloads. It is not an either-or; it is a toolbox.

FAQ: Does sandboxing replace a VM or antivirus?

No, it complements both. Antivirus tries to detect known threats; sandboxing limits the damage of unknown ones. A VM draws a kernel boundary for genuinely untrusted code; a sandbox constrains trusted apps that process hostile input. The right answer is defense in depth: sandbox for daily work, VM for analysis, current patches as the baseline.

Practical takeaway: start today

Practical takeaway: start today by running flatpak override --user --nofilesystem=home on every installed Flatpak app, swap your default PDF reader for a Bubblewrap wrapper bound only to ~/Downloads, and version those scripts in a private repo. In one afternoon you raise the exploitation bar of your desktop more than a year of reactive patching. Properly configured sandboxing wont stop every intrusion, but it guarantees the months first browser CVE wont mutate into an SSH-key-leak incident. The ROI of this setup is measured in incidents that never happened.