[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

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.

http://man7.org/linux/man-pages/man7/capabilities.7.html

https://en.wikipedia.org/wiki/Chroot#Limitations

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?

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.

2 Likes

Thanks!

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?

1 Like

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.

3 Likes

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.

@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.

2 Likes

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.

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]