Tor Browser Hardening (hardened malloc, firejail, apparmor) vs Web Fingerprint

I have given many already.

Bubblewrap is also used by thousands. It’s used internally by flatpak and likely has far more users than firejail.

This isn’t a popularity contest either.

I gave two examples.

He is one. He has submitted tons of hardening patches upstream to the Linux kernel, OpenBSD, AOSP and more. He’s the guy behind linux-hardened, GrapheneOS, CopperheadOS, hardened_malloc and more. He was even part of the KSPP.

I don’t see why you’re so against him.

He does have strong arguments.

I’ve already proved it’s harmful to security.


Still not a security expert and still irrelevant to this discussion. You’re trusting free software advocates over actual security experts who know what they’re doing.

i dont want to repeat my points which are opposing the arguments you are proposing thus i will wait to collect experts ideas about that, but here is where the good start begin:

you said:

can you start doing that and let us see how far its user friendly?

I haven’t mentally processed all input in this thread yet.

I don’t want to act too quickly here (within days). After the amount of work that has flown into firejail (sunken cost fallacy…), it would be awful to remove it in case security experts are undecided about it. Therefore taking more time to find positives about it.

bubblewrap: I wouldn’t want to act too quickly here too at the risk of further wasted effort. This isn’t a popularity contest but a (less) active or inactive upstream which leads to it being deprecated would result in wasted effort too. This also needs to be researched.

Asked @TNT_BOM_BOM to help finding positive statements about firejail and negative statements about bubblewrap. (Quite a bias on a second thought.) This is a result of it:

I have already done that and no, free software guys aren’t experts in this topic.

Assuming the bubblewrap sandboxes are stored in /etc/bwrap/.

Bubblewrap isn’t less active. They’re just wary of new features due to not wanting to increase attack surface.

Obviously asking on the firejail github repo will get biased responses.


  • I am not fully convinced, that firejail is bad.
  • Decided to no longer install firejail by default in Whonix anyhow.

firejail security

Can’t rely too much on Daniel Micay as security export because he’s (often justified…) critical on “everything”… Could as well as give up and go home following that sentiment. Reference: Daniel Micay Quotes

Firejail developers might be bias towards firejail.

Bubblewrap developers might be bias towards bubblewrap.

Under the bias thesis, both candidates aren’t ideal expert opinions here on judging the security of each tool vs each other. Their input is valued nonetheless.

Tried to wrap my head around this issue. Made some notes here:
Dev/Firejail - Kicksecure

Trying to come up with essential questions.

Please keep expert opinions pro/contra firejail / bubblewrap / apparmor / etc. coming.

installation by default

Whonix doesn’t enable any firejail / bubblewrap profiles for anything by default yet. All such profiles are opt-in.

Whonix comes with some apparmor profiles by default. Those for its own software and those profiles maintained by Debian. Other profiles are opt-in.

Decided to no longer install firejail by default due to

  • the controversy,
  • higher attack surface without other advantage by default (no profiles enabled by default).

Currently Whonix has a by default a higher attack surface (due to firejail installed by default) but no security advantages (not making use by default of any firejail profiles).

Firejail was only installed decided to become installed by default for better usability. To make writing firejail profiles easier. This could be undone since we did not get any new profiles anyhow.

At the moment, major attack surface realistically is the browser, Tor Browser. If hypothetically upstream, The Tor Project maintained a firejail profile, then I would think that the security advantages outweight the security disadvantages of it. Until in-the-wild attacks proof otherwise. That would be a reason to keep firejail installed by default.

SecBrowser depends on firejail and uses it by default. But SecBrowser isn’t Whonix. For SecBrowser I’ll keep firejail enabled by default until I am convinced that it does more harm than good against realistic attacks (what happened previously in-the-wild).

future reconsideration for re-installation of firejail

  • Anyone maintaining firejail profiles in Whonix for software not developed by Whonix wouldn’t be installed by default - same as for apparmor profiles.
  • Anyone maintaining firejail profiles in Whonix for software developed by Whonix, and re-installation for firejail by default would be reconsidered.
  • Anyone maintaining firejail profiles in Debian, and re-installation for firejail by default would be reconsidered.

He’s only critical on things that deserve it.

The recent thread shows a majority of people “pro-firejail”. I’m really the only one “pro-bubblewrap”.

Firejail’s large attack surface is already well known.

It may have made privilege escalations easier. I originally thought you meant if it helped those attacks, now I see you meant if it helped against. Those attacks are mainly IP leaks which firejail doesn’t try to prevent.

It’s one of the most popular linux sandboxing programs and is a very vulnerable target. It’s not very unlikely.

There’s more pro bubblewrap quotes by Micay (these have nothing to do with firejail).

Everything else is better served by

The problem also isn’t likely to change even years from now. It’s still going to be a poorly designed feature with much better approaches like the one taken by bubblewrap which exposes much less attack surface.

There are projects like flatpak / bubblewrap providing alternatives to user namespaces that are more secure.

After reading Firejail devs’ responses I really respect them. That’s some of the most neutral and helpful commentary I’ve seen.

netblue30 plainly recommends that for our threat model we focus on a tight full system MAC policy and forget about sandboxing altogether as it is meant to raise the security baseline of single user systems rather than be a solution for servers. That’s the main thing and you should stop reading here if you’re wondering what to do next.


I don’t agree with that. Namespaces and seccomp are extremely important and apparmor doesn’t use them.

Seccomp especially is important as it can greatly reduce kernel attack surface.

1 Like

They admit for stuff running outside the sandbox the attack surface is larger than bubblewrap and theoretically enables easier privilege escalation. On the other-hand this doesn’t apply to stuff in the sandbox. Firejail’s comprehensive selection of application profiles would limit this scenario.

Once inside a sandbox - firejail, bubblewrap, or any other seccomp sandbox - you can not exploit any SUID executable present in the system. It has to do with the way seccomp is handled by the kernel. The attack surface of the program that configured seccomp becomes irrelevant. In other words, if you get control of a firefox running in a sandbox, the kernel wouldn’t let you exploit the program that started the sandbox.

Meanwhile since you have the skills to actually forge a solution that combines the best of both world’s we can have our cake and eat it too:

Yes, bublewrap has less additional attack surface for scenario 2 but merely installing bubblewrap does nothing for scenario 1 unless someone write special wrapper for it with profiles for many specific apps. Something like that, let’s call it Firewrap or Bubblejail would be interesting, perhaps more secure solution than firejail but for now it doesn’t exist.

1 Like

How would bubblewrap in the Workstation work? IDoes bubblewrap have commands and profiles that need to be implemented on a per-app basis, or is this done through config files? I saw the comment about using wrappers for it, but am not exactly sure

1 Like

It doesn’t really have profiles. It’s only meant to be used as a command. To create a “profile” you need to create a wrapper script for the program that uses bwrap. e.g.:

bwrap \
--dev-bind / / \
--unshare-all \

This is a very basic example. See the other example I linked above to get a better idea.


after all comments and thank you @madaidan for bringing this up i have concluded:

  • Firejail isnt yet matured , we should give it time like what apparmor been given before and see later. So removing it better (agree with @madaidan)

  • Firejail or Bubblewrap isnt the equation , but getting rid of them until they are matured and adopted by debian like apparmor and see after that (i agree with @Patrick)

  • Whonix was already working with/on apparmor before , since apparmor now part of debian we should continue carry on using it plus MAC (i agree with @HulaHoop on that)

  • Daniel Micay views not worthy , hes mistakenly in love with google/proprietary and his views unproductive on anything to be used here.

  • Some projects considering non of the above is any better e.g:

Ideally for whonix now is to not use except what already was using and keep improving it (mostly what netblue30 suggested)

Firejail is matured. That’s the worst part.

Both are matured and bubblewrap is even adopted by flatpak which is widely used.

Hulahoop was quoting netblue, hulahoop didn’t give his opinion on that and as I’ve already said, namespaces/seccomp are important which aren’t provided by apparmor.

His views are far more worthy than any of ours. Take your pointless insults elsewhere.

You do realise gvisor is made by google, right? Doesn’t using google software make you mentally sick now according to you?

No , meant by maturity to be adopted by debian.

It doesnt matter where are/it using both of them just not worth the headache of using atm

important when there are matured tools, not now.


Never said oh we should use it , never said its any better. All what said is opinion from another project thus i already said to not take any of these projects and ideally stay on what was whonix using.

Being adopted by debian is not a requirement for maturity. The main bubblewrap devs are even debian devs which should be a step in your view of “maturity”.

It is worth it. Namespaces and seccomp are really useful.

They are matured tools. Bubblewrap is used by thousands of people and recommended by security experts. How is that not mature?

It’s not just an opinion, it’s slander.

1 Like

when used by default on debian thats the turn part im talking about, not who developed it.

same answer before.

not matured in the way that it should be matured like i described it

Sorry not productive one according to his shitty views on everything except almighty proprietary.

In the end this my views , im not the one who decide what to install and what not to install and do all the bugs solving and related work this is @Patrick job and decision. We are here to share our views, and my position is software tester if bubblewrap included or not i will test in both cases.

Being used by default on debian is also not a requirement for maturity.

Whonix used apparmor long before it was the default on debian yet I haven’t seen any criticisms from you about it.

The answer before is “it’s not worth it” with no other explanation.

It’s extremely important. Without, seccomp a huge amount of kernel attack surface is exposed. For example, unprivileged programs can even mess with kernel memory faults with syscalls such as userfaultfd or privileged programs can gain read-write access to memory with syscalls such as ioperm or iopl.

No, that’s complete misinformation. He only criticises things that deserve criticism including many proprietary things.

I don’t see why you keep going on about proprietary stuff when he’s a massive contributor to open source projects. Whonix is using a lot of his work already.

  • bubblewrap will be installed by default after upgrades.
  • bubblewrap will also be installed by default in Whonix (and above).

But not because any decision / change by Whonix.

bubblewrap is a dependency.

sudo apt dist-upgrade and even sudo apt dist-upgrade --no-install-recommends on Whonix-Gateway will install bubblewrap. Technical reasons (dependency chain):

  • libwebkit2gtk-4.0-37 depends on bubblewrap
  • zenity depends on libwebkit2gtk-4.0-37
  • msgcollector-gui depends on zenity
  • tb-updater depends on msgcollector-gui (zenity progress bar, tb updater gui)
  • whonixcheck (--gui) needs zenity (zenity progress bar)