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.
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.
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?
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.
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.
@patrick
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.
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.
For future reference, please see this discussion to understand why removing these capabilities actually makes things less secure: Redirecting to Google Groups
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.
