Sandboxing Open-Source Games on Linux: Flatpak, Firejail & AppArmor Profiles

18 Aug Sandboxing Open-Source Games on Linux: Flatpak, Firejail & AppArmor Profiles

To sandbox open-source games on Linux, you can use Flatpak for automatic bubblewrap isolation, Firejail for custom profile-based confinement, or AppArmor for kernel-level mandatory access control.

This guide covers all three approaches with copy-paste commands and a decision matrix to help you choose the right tool for your threat model. If you’re running games on a workstation that also handles SSH keys, GPG keyrings, or sensitive development data, unsandboxed game processes are a real risk you shouldn’t ignore.

Why Gaming Binaries Are a Legitimate Attack Surface

Open-source games aren’t inherently malicious, but their install scripts, auto-updaters, and embedded scripting engines run with your full user-level filesystem access by default. A game that loads community mods or phones home for leaderboard data expands your network and code-execution attack surface every time it launches.

On a hardened desktop used for sensitive work, an unsandboxed game process runs with the same privileges as your SSH agent. That means it can read ~/.ssh/, access your browser profile, and write to any path your user owns. If a game binary is compromised through a malicious mod or supply chain attack, the blast radius is your entire home directory.

The fix isn’t to stop playing games. The fix is isolation.

Tool Comparison: Flatpak vs. Firejail vs. AppArmor

Which Linux sandboxing tool is best for gaming? The answer depends on your environment, but this table gives you the decision criteria upfront.

Tool	Isolation Mechanism	X11/Wayland	Setup Complexity	Best Use Case
Flatpak	bubblewrap namespaces + portals	X11 exposed by default; Wayland via portals	Low	Packaged games from Flathub
Firejail	SUID namespaces + seccomp-bpf	X11 configurable; Wayland partial	Medium	Native binaries with custom profiles
AppArmor	MAC policy via LSM hooks	Controlled by policy rules	High	Layered enforcement on any binary

Flatpak is the lowest-friction option for packaged games. Firejail handles native binaries well when you write or audit a proper profile. AppArmor enforces mandatory access control at the kernel level and pairs cleanly with either of the other two.

Locking Down Flatpak Game Permissions

Flatpak uses bubblewrap to create isolated namespaces for packaged applications. The problem is that many Flatpak-packaged games ship with permissive default permissions, including broad filesystem access and unrestricted network, that you need to override manually.

Audit Current Permissions

Start by seeing what a game actually requests:

flatpak info --show-permissions org.supertuxkart.SuperTuxKart

Look for filesystems=home or filesystems=host. Either grants far more access than a game needs. Network access listed without a specific socket restriction is also a red flag on a sensitive workstation.

Restrict with flatpak override

To remove home directory access from a Flatpak game, run flatpak override --user --nofilesystem=home followed by the application ID:

flatpak override --user --nofilesystem=home org.supertuxkart.SuperTuxKart
flatpak override --user --unshare=network org.supertuxkart.SuperTuxKart
flatpak override --user --device=dri org.supertuxkart.SuperTuxKart

The --device=dri flag passes through only the GPU render nodes, not all host devices. Verify the override is active before launching:

flatpak override --user --show org.supertuxkart.SuperTuxKart

One known limitation: Flatpak’s X11 socket access. When a game runs under X11, it gets access to the full /tmp/.X11-unix/ socket, which means it can read keystrokes and screen content from other X11 clients in the same session. Flatpak’s bubblewrap isolation doesn’t close this gap without additional steps.

Running Native Game Binaries Under Firejail

Firejail uses Linux namespaces and seccomp-bpf filters to confine native binaries. It’s the right tool when you’re running a game downloaded as a tarball or installed outside a package manager.

Build a Custom Firejail Profile

Start from the generic template at /etc/firejail/generic.profile and customize it. Here’s a working baseline for a game that needs GPU, audio, and a save directory:

# supertuxkart.profile
include /etc/firejail/disable-common.inc
include /etc/firejail/disable-passwdmgr.inc

private-tmp
net none
noroot
nosound off
whitelist ${HOME}/.local/share/supertuxkart
whitelist ${HOME}/.config/supertuxkart
read-only ${HOME}
noblacklist /dev/dri
noblacklist /dev/snd
apparmor

Launch the game under this profile:

firejail --profile=/etc/firejail/supertuxkart.profile /usr/bin/supertuxkart

Use firejail --debug and firejail --trace to identify denied syscalls or missing path allowances. Don’t guess. Let the trace output tell you exactly what the binary needs, then whitelist only that.

One honest limitation of Firejail: it runs as a SUID binary. That attack surface is real. On systems where the SUID risk is unacceptable, pair Firejail with AppArmor to constrain Firejail itself.

Authoring an AppArmor Profile for a Game Binary

AppArmor enforces mandatory access control by attaching a policy to a specific binary path. Even if a game process is compromised, the kernel enforces the policy regardless of what the process tries to do.

Generate a Base Profile with aa-genprof

1. Run sudo aa-genprof /usr/bin/supertuxkart to start the learning mode session.
2. Launch the game and play through typical scenarios: menus, a race, audio, save/load.
3. Return to the aa-genprof prompt and press S to scan the log for access events.
4. Review each flagged access and allow or deny it interactively.
5. Press F to finish and save the generated profile.

Refine the Profile

Check denial events in real time:

journalctl -f | grep DENIED

Use aa-logprof to iterate without editing rules manually:

sudo aa-logprof

Here’s a minimal AppArmor profile snippet showing deny rules for sensitive paths:

/usr/bin/supertuxkart {
  #include <abstractions/base>
  #include <abstractions/audio>
  #include <abstractions/dri-enumerate>

  /usr/bin/supertuxkart mr,
  /usr/share/supertuxkart/** r,
  owner @{HOME}/.local/share/supertuxkart/** rw,
  owner @{HOME}/.config/supertuxkart/** rw,

  deny @{HOME}/.ssh/ r,
  deny @{HOME}/.gnupg/ r,
  deny /etc/passwd r,
  deny /proc/*/mem r,
}

Enforce the profile and verify:

sudo aa-enforce /usr/bin/supertuxkart
sudo aa-status | grep supertuxkart

Closing the X11 Socket Escape Vector

X11 socket access is the gap that most sandboxing guides skip. Any process with access to the X11 socket can read keystrokes and screen content from other X11 clients in the same session. A sandboxed game with X11 access can escape the sandbox’s intent entirely.

Xpra creates an isolated X11 server that proxies display output without sharing the host socket. Wrap your game launch with it:

xpra start :100 --start-child="firejail /usr/bin/supertuxkart" --exit-with-children

The game renders inside Xpra’s isolated display. Your host X11 session stays clean. For Wayland users, native Wayland games don’t have this problem. XWayland still shares some attack surface, but it’s narrower than a full X11 session. Migrating games to Wayland-native rendering is the long-term answer where the game supports it.

Combining Firejail and AppArmor for Layered Isolation

Firejail and AppArmor enforce at different layers. Firejail handles namespace isolation and seccomp syscall filtering. AppArmor enforces MAC policy at the kernel level. Running both simultaneously gives you defense in depth without meaningful performance overhead.

Enable AppArmor enforcement from within a Firejail profile by adding the apparmor directive:

# In your .profile file
apparmor supertuxkart

Verify both layers are active before treating this as production-ready:

firejail --list
sudo aa-status | grep enforce

Sandbox Validation: What to Check Before You Ship It

Don’t assume isolation is working. Verify it.

• Place a canary file at ~/.ssh/canary.txt and confirm the game process cannot read it.
• Run flatpak override --user --show <app-id> to confirm overrides are applied.
• Check sudo aa-status to confirm the game binary is in enforce mode, not complain mode.
• Run firejail --list to confirm the game process is running inside a Firejail sandbox.
• Monitor journalctl -f | grep DENIED during gameplay to catch unconstrained child process transitions.
• Verify network isolation with firejail --net=none and confirm the game can’t reach external hosts.
• Check for child process spawning (shader compilers, audio daemons) and confirm they inherit the AppArmor policy or have their own Px transition rules.

Silently permitted access through an unconstrained child process is how sandboxes fail in practice. The AppArmor denial log is your audit trail. Read it after every gameplay session until the profile is stable.

Running games on a workstation that handles sensitive data is a real operational scenario, not a theoretical one. The tools to isolate those game processes exist, they work, and the configuration is manageable. Pick the right tool for your threat model, layer where it makes sense, and verify before you trust.

Frequently Asked Questions

Does Flatpak sandbox games automatically?

Flatpak applies bubblewrap namespace isolation automatically, but the default permissions many games ship with are permissive. You need to audit permissions with flatpak info --show-permissions and apply overrides with flatpak override to get meaningful isolation.

Can Firejail break game audio on Linux?

Yes, if your Firejail profile doesn’t whitelist the PulseAudio or PipeWire socket paths, audio will silently fail. Add noblacklist /dev/snd and ensure the audio abstraction path is accessible in your profile to restore sound.

Is AppArmor better than Firejail for sandboxing games?

They address different layers. AppArmor enforces mandatory access control at the kernel level and can’t be bypassed by the confined process. Firejail adds namespace and seccomp isolation on top. For maximum confinement, run both together using Firejail’s apparmor directive.

How do I run a Linux game in a sandbox without breaking GPU access?

For Flatpak, use flatpak override --user --device=dri to pass through only GPU render nodes. For Firejail, add noblacklist /dev/dri to your profile. For AppArmor, include the dri-enumerate abstraction in your policy file.

How do I restrict game network access on Linux with Firejail?

Add net none to your Firejail profile to block all network access. If the game requires online features, use net eth0 with specific port restrictions instead of blocking everything, then verify with firejail --debug to confirm the rules apply correctly.