firejail / seccomp / More Options for Program Containment


Worth checking out… Quote: Tails report for January, 2016

Change to systemd as init system and use it to:

  • Sandbox many services using Linux namespaces and make them harder to exploit.

systemd SystemCallFilter= containment option seccomp hardening


Is this a firejail bug or a feature request for a non-standard way we do things?

EDIT: seems symbolis took care of it :slight_smile:


I think both mechanisms compliment each other - systemd for services and Firejail for Desktop programs.


I meant checking out any containments they configured for “many services”. Perhaps we can re-use their work.


I think this means they are going to make use of it later but nothing has been done with it yet. They just switched to it recently.

My searches of their git logs hasn’t turned up anything useful:



https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/lib/systemd/system but does not look like something portable.


The Tor Project firejail start-tor-browser bug report:
strange Tor control auth cookie default path

The bug report got a wontfix, but at least now these variables are configurable by environment variables. Reference:


Process sandboxing coming to FF sometime this year. Its not as robust as the syscall whitelisting Firejail can do but its a good move and stackable with other protection.



New proof of concept TBB isolation profile this time using bubblewrap - a subset of Flatpak:


Not really ready for use but shows progress in this area.


FireFox sandbox lands in nightly. They are working on tightening it up some more:

KDE Flatpak progress:



As Yawning’s Tor Browser Firejail profile (script?) is no longer available at the link in the dev wiki, I suppose the standard Firejail FF profile is sufficient when starting Tor Browser in Whonix or Qubes-Whonix.

See discussion in “Hardening Qubes-Whonix” thread and suggested wiki entry over there for background & motivation. Basically I want to polish off the instructions so normal people can use it consistently.

Most of the primary security features seem to be enabled in the Firejail profile for Firefox already e.g. seccomp, caps.drop all etc:[1]

cat /etc/firejail/firefox.profile


# Firejail profile for Mozilla Firefox (Iceweasel in Debian)

noblacklist ~/.mozilla
noblacklist ~/.cache/mozilla
include /etc/firejail/disable-common.inc
include /etc/firejail/disable-programs.inc
include /etc/firejail/disable-devel.inc

caps.drop all
protocol unix,inet,inet6,netlink

whitelist ${DOWNLOADS}
mkdir ~/.mozilla
whitelist ~/.mozilla
mkdir ~/.cache/mozilla/firefox
whitelist ~/.cache/mozilla/firefox
whitelist ~/dwhelper
whitelist ~/.zotero
whitelist ~/.vimperatorrc
whitelist ~/.vimperator
whitelist ~/.pentadactylrc
whitelist ~/.pentadactyl
whitelist ~/.keysnail.js
whitelist ~/.config/gnome-mplayer
whitelist ~/.cache/gnome-mplayer/plugin
whitelist ~/.pki

# lastpass, keepassx
whitelist ~/.keepassx
whitelist ~/.config/keepassx
whitelist ~/keepassx.kdbx
whitelist ~/.lastpass
whitelist ~/.config/lastpass

whitelist ~/.wine-pipelight
whitelist ~/.wine-pipelight64
whitelist ~/.config/pipelight-widevine
whitelist ~/.config/pipelight-silverlight5.1

include /etc/firejail/whitelist-common.inc

# experimental features
#private-etc passwd,group,hostname,hosts,localtime,nsswitch.conf,resolv.conf,gtk-2.0,pango,fonts,iceweasel,firefox,adobe,mime.types,mailcap,asound.conf,pulse

This profile is probably okay for Firefox-ESR in a straight Debian VM, but there might be further black-listing for stuff for Tor Browser in a Whonix VM.

I don’t understand that stuff about -X11 and -Xpra options (normal user here). It seems desirable because it prevents screenshots and keyloggers from accessing stuff in other displays outside of the container. Does this mean that nothing outside of the Firefox-ESR or Tor Browser VM can be snap-shotted or logged e.g. stuff running in parallel in another VM in Qubes?

@HulaHoop are you running a (working) Tor Browser Firejail profile that is heavily modified from the above in Whonix? If so, do you mind pasting it so I can reference it for other users to try?

[1] See https://firejail.wordpress.com/features-3/man-firejail/


Can firejail even be combined with bubblewrap sandboxed Tor Browser?


No haven’t looked into it since. Now that there is an officially supported solution you should use it instead. I don’t think there is much benefit from stacking two tools that do the same thing.


Ok - thanks.

The problem is though:

  • bubblewrap is currently incompatible with any Qubes VM, meaning the alpha Tor sandbox doesn’t work in straight Debian VMs or Whonix VMs in Qubes-Whonix (see Patrick’s efforts); and
  • 32 bit binaries are no longer being built for the alpha Tor sandbox, which I thought meant that this will now be incompatible with 32-bit non-Qubes-Whonix.

Thus, Firejail is the only working solution for Qubes-Whonix & non-Qubes-Whonix currently. I don’t expect either of these problems will be solved anytime soon (bubblewrap & 64-bit non-Qubes-Whonix).

See here:


I see. Well I know for non-Qubes Whonix the next release (14) will be 64bit. So this is done.


Made some edits, some things don’t play out es expected:

Documentation enhancements suggested by @torjunkie, currently discussed here:


This might be better for the Firejail instructions for Tor Browser i.e. how to properly incorporate the Firefox profile (haven’t tested it yet, but will soon):


You can use Tor Browser with Seccomp via Firejail, like this:

$ cat /etc/firejail/tor-browser.profile
noblacklist ~/.tor-browser-en
include /etc/firejail/firefox-esr.profile
whitelist ~/.tor-browser-en

$ firejail --seccomp --profile=/etc/firejail/tor-browser.profile /usr/bin/tor-browser-en



Flatpak sandboxed program support lands for KDE’s repo manager