Why does the Tor Browser AppArmor profile have sys_admin, sys_chroot and ptrace capabilities?

The Tor Browser AppArmor profile has capability sys_admin,,
capability sys_chroot, and ptrace. This looks pretty insecure.

ptrace will allow the Tor Browser to modify and inspect other running processes.

sys_admin will allow the Tor Browser to do a whole load of things that it probably shouldn’t be able to.

sys_chroot will allow the Tor Browser to chroot which can make an attacker able to put a setuid program inside a chroot jail with a fake /etc/passwd and /etc/shadow which can fool it into giving it root access.



Are these needed for anything? I think they should be removed.

1 Like

Why? It was contributed, now unmaintained. Not a good reason to keep is
improvement is possible. Patches welcome.

Could you please compare with other Tor Browser apparmor profiles such
as the one from torbrowser-launcher github?

1 Like

The one from the torbrowser-launcher github is more locked down than the Whonix one. Most likely because the Whonix one has to be designed specifically for Whonix. It also doesn’t have any capabilities.

The Tails one is very similar to the torbrowser-launcher one. It’s just adapted for Tails.



Sounds good. Patches welcome.

1 Like

Just created a pull request for it.

There are also some other unnecessary permissions such as support for audio, KDE and VPNs. I think these should be disabled by default by commenting them out so it makes it easier for people wanting to re-enable those. What do you think?


Regarding capabilities, after they were removed from the profile, Tor Browser is enforced. But, because kern.log complains about missing cap_sys_admin, the rest of the profile seems to be ignored.

That is, we can comment most of the entries (except for TB own directory) without any denied messages.

After reinstating capability sys_admin, we need sys_chroot because no tab would open.

I am not a kernel guru. Should we live with a probably shaky profile, or allow a possibly unsecure feature?

sys_admin is not root. http://man7.org/linux/man-pages/man7/capabilities.7.html

Tested with TB alpha, no differnce.


I’ve just realised that these capabilities are likely required for firefox’s built-in sandbox. That’s probably why things are breaking.

cap_sys_admin seems to be related to namespaces and seccomp which firefox’s sandbox uses and cap_sys_chroot is needed for chroot which firefox also uses.

These should probably be added back but those capabilities can be dangerous.

1 Like

Should I revert https://github.com/Whonix/apparmor-profile-torbrowser/pull/6?

1 Like

Yes. Maybe add some comments to the file explaining the use of the capabilities so there isn’t any more confusion.

1 Like

Done in git master.

1 Like

Just a thought. Firefox runs in its own sandbox, and the AppArmor sandbox is added on top of it in Tor Browser. Adding a couple of capabilities, even sys_admin, is perhaps a compromise.

Firejail comes with a bundled AppArmor profile. From memory, I believe it includes most of the linux capabilities.

The point of this post is that ptrace is no longer required, probably because it’s “employed” by capabiliy_sys_admin.

signal doest not seems to be required either, without any obvious reason, but that’s Tor Browser…

Pushed the changes to the profile. The extra line in the commit is removed in the next one.

I have installed the profile from the apparmor-profiles-hardened-debian package. Wanted to clone it, but I cannot find it in github whonix/master.


Merged. :slight_smile:

That’s just a meta package. It is declared here:

Btw: https://www.whonix.org/wiki/Dev/git#grep_Whonix_source_code

ptrace isn’t really a concern anymore as we use the YAMA LSM now (kernel.yama.ptrace_scope=2 is set with sysctl). It would only be able to use ptrace if it had root access.

1 Like

Thanks for the explanation. :slightly_smiling_face:

I was going to ask why we could not set kernel.yama.ptrace_scope to 3, but after re-reading the documentation, looks like it would not be reversible.


To ensure this cannot be too badly exploited, we can use extended capability rules.



gcp commented 10 hours ago on github:

For future reference, please see this discussion to understand why removing these capabilities actually makes things less secure: https://groups.google.com/forum/#!topic/mozilla.dev.platform/UK4nm7MtTxQ

1 Like

I was wondering something about this; I read on github as well on google-groups and tried something. I have a working Tor Browser Apparmor profile that I use on Debian. It has every capability denied explicitly except “mknod.” Every other one is explicitly denied in an abstraction (each cap has a rule like this: audit deny capability_foo).
On the about:support helper page in Tor Browser, there is a section on sandbox with some useful descriptions and boolean values. When I have Apparmor on and in enforce mode, or with Apparmor explicitly put into complain mode, the settings remain the same:

Seccomp-BPF (System Call Filtering) true
Seccomp Thread Synchronization true
User Namespaces for privileged processes true
User Namespaces false
Content Process Sandboxing true
Media Plugin Sandboxing true
Content Process Sandbox Level 4
Effective Content Process Sandbox Level 4

It looks like the built in sandboxing from Mozilla is still working as it should regardless of Apparmor. I even tried with and without Firejail along with Apparmor and still the result is the same.

1 Like

one can disable Mozilla containers (used by multiple tabs).

I’d say tighten the sys_admin and start providing a user.js that works with Whonix OS.

There was a minimal modification to user.js in past and that went horrible, easily broken. (add Tor Browser first startup popup to ask whether security slider should be set to safest)

Hence, please kindly consider to suggest and/or implement that upstream in Tor Browser at The Tor Project.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]