firejail / seccomp / More Options for Program Containment


But ‘presumably’ the profiles are only going to get tighter, not looser.

Is that really different than any other package?

Further testing here reveals the software isn’t ready for prime time. Despite ‘firejail --net=eth0 -ip= qbittorrent’ no network activity was observed 2 out of 3 goes.

Hate to be a downer on my own “hey, this is out there”, but if I’m the first one to call for such containerization, there can’t be a crying need for it out there - IMO whonix resources are probably better spent elsewhere.

However, the topic of containerization, value, and heft, in a whonix context, does seem a worthy topic to keep an eye on.

Regardless of the mechanism used, e.g. docker in single application mode seems like an equally likely candidate, vs LXC full OS turnkeys - the idea of user chosen optional ‘safe app kiosk install’ seems to have merit.

If you turn the concept around, one could also see a series of ‘whonix-apps’. e.g. A whonix container installable in any system (if, e.g., a docker image), blessed as being a whonix approved anonymous (anonymizing & scrubbed/ing) turnkeyed app window.

My guess is such would be useful within qubes as well, but I expect qubes has its own equivalent mechanism already.

LXC, cgroups, ip netns, docker, vboxes, et all, seem to have come a long way. The common concepts and intents behind them seem to have many ongoing candidate implementation methodologies at various stages of development.

If I was the first to ask about firejail, … is such really all that popular a desire worthy of allocation of whonix resources?
(Says the guy that made the original request of consideration.)

need a maintainer to create such profiles since I guess it’s non-trivial work, non-negligible time effort and not free
of issues.

Profiles are really simple, so I don’t think that’s a huge burden - BUT: that makes the assumption of familiarity of containerization/LXC, etc.

I am not, so, for example, I have no idea of the pros / cons / appropriateness of the ‘seccomp’ profile directive.

In testing, I disabled a ‘noroot’ directive - aside from the LXC concepts, one would be trusting, on a per app basis, whether ‘noroot’ or not is dangerous / suitable (in a whonix context) - and for that one would have to be very familiar with the particular app, and probably its internals.

e.g. One might ask, does ‘kmail’ need ‘noroot’ not specified, or not. One might reasonably ask, why would it need root? I expect the only one who could reasonably answer such a question is one familiar with kmail internals - and there quite probably aren’t a great deal of such around. [I expect the biggest reason for noroot is apps place files in far too many unusual/unexpected places, and noroot is expedient for getting an app to run without fully understanding all the places that must be black/white-listed, exceeding the bound of the container in the process. Or at least the container being larger than it should / needs to be.] And such an app expert would be needed per app. And there are several dozen apps in there already.

One thing I noticed with my testing of ktorrent, is D-Bus use and forking apps are problematic for firejail. If whonix is by design a KDE install, and firejail is KDE broken … I came to the conclusion of hurry up and wait for further firejail maturity before looking at it any more deeply.

At least until they can demonstrate that ‘firejail --no-profile --net=eth0 {any candidate kde app}’ “just works.” (–no-profile = no restrictions, --net=eth0 = containerized network stack). i.e. To the user, ‘myapp’ and ‘firejail myapp’ should present identically without further user intervention. (Things can be made tighter, but at its loosest, it should be transparent to the user as to which way it’s running.) Seamless / transparent user use is not the case today, and it may be prudent to wait until it is.


depends on kernel version

This refers to a time when seccomp was being baked into Linux.

Your comparison is not really accurate. Read the Firejail FAQ that answers this question: https://firejail.wordpress.com/support/frequently-asked-questions/

Summary: Firejail and its supporting tools are geared towards the desktop usability and building security profiles while Docker/LXC is built for virtualization and resource partitioning on servers.

Firejail is also getting attention from the security community and has been audited recently:

Please report the problems you run into with Firejail profiles to the devs so they are corrected by the time Debian Stretch stabilizes.


Firejail workflow usability enhancement:

Ticket accepted :slight_smile:


Ticket implemeted!


Ticket accepted.



Feature already exists under --no-sound option.

Xpra gui isolation support landed in git and documented here:



subgraph’s seccomp profiles:

Apparently these are not compatibly with firejail?



Apparently these are not compatibly with firejail?

Not compatible because different profile sematics/programming language for each. For things like whitelisted seccomp syscalls it is simple enough to read them from one profile and add them for the same program under Firejail profile.


Could we have firejail and oz both installed at the same time? Will firejail and oz be compatible as long as they do not try to confine the same application? And what happens if firejail and oz try to confine the same application?

Did someone test oz on Debian yet?


Firejail 9.40 released with X11 isolation support, file transfer capability and much more.



Discussed ways to make programs run under Firejail automatically out of the box. This can be taken further by optionally making other programs without a profile run seamlessly under the generic containment profile. Also mentioned Oz’s technique in tackling this if it turns out my idea can’t work.






To integrate with Firejail, the script developed by Yawning is meant to replace the one in this path: /home/user/.tb/tor-browser/Browser/start-tor-browser

Can you open a ticket against TPO please to merge firejail start-tor-browser into Tor Browser? In a - if firejail is installed, use it - otherwise just function as usual, there should no objection. And cc yawning.





Would like your comments on some points: https://www.whonix.org/w/index.php?title=Dev/Firejail&stable=0#Integration_Roadmap


Please try to avoid these strange links. They are probably a bug. Something mediawiki messed up since the upgrade. I don’t think this is something they did on purpose. Please use the normal links. You can get them by reloading the page. Ex: https://www.whonix.org/wiki/Dev/Firejail

Firejail should probably get its own Whonix helper package to include custom profiles (Yawning’s TBB). Xpra dependency should be coded there.

I’d say it to https://github.com/Whonix/apparmor-profile-torbrowser. (The clean way would be to rename the packatge to containment-profile-torbrowser but let’s skip this overhead.)

Changes to TBB launchers required.

This is very bad because these come with TBB which has no Debian package. And TBB internal updater does not support post update hooks (feature request against TBB exists but will not be implemented). So I would not know how to keep it active after TBB upgrades unless inventing a hack inotifywait or so (but even then there could be race conditions). Launches changes really should be submitted upstream.

Decide on whether to introduce pinned packages

Decide if firecfg should be scripted to enable all profiles by default.

Please submit a feature request against upstream firejail or Debian. (Whenever more appropriate, probably Debian?) This also makes a lot more sense upstream than Whonix specific stuff.

Decide on application launcher paths.

There is https://github.com/Whonix/tb-starter/blob/master/usr/share/applications/janondisttorbrowser.desktop but that would not work when starting Tor Browser manually from its data folder ~/.tb/tor-browser.


Decide on application launcher paths.

There is https://github.com/Whonix/tb-starter/blob/master/usr/share/applications/janondisttorbrowser.desktop but that would not work when starting Tor Browser manually from its data folder ~/.tb/tor-browser.

On a second thought, it is better to add the if firejail is installed, automatically use it, otherwise skip it, stuff here:

(Because then it would work when starting firejail from the desktop launcher and using torbrowser from the command line. [But not when starting it from ~/tb/tor-browser.])

And perhaps an option (disabed by default) “tb_not_use_firejail_even_if_installed”.


Its better to keep the TBB apparmor profile separate from Firejail’s just in case a user wants to uninstall either one because of unforeseen bugs affecting either.

No feature request needed - what I’m looking for is a simple wrapper script that executes “sudo firecfg” creating all the symlinks for apps with a profile available. So protection is activated out of the box on Whonix. A systemd service file can probably do?

Sounds good though above my skills. Please include this whenever you can.