Feature #16432

Allow Tor Browser to view other HTML files in /usr/share/doc

Added by sajolida 13 days ago. Updated 9 days ago.

Target version:
Start date:
Due date:
% Done:


QA Check:
Feature Branch:
Type of work:
Affected tool:


Right now, the AppArmor profile of Tor Browser in Tails only allows viewing files in `/usr/share/doc/tails/website`.

For example, if I install ikiwiki, I have no way of viewing the HTML documentation included in the package.

We are also facing this problem in Whiskers where it's currently impossible to view the doc included in the Debian package:

So relaxing the AppArmor limitations on `/usr/share/doc` make sense in 2 different contexts that Tails wants to support:

What would be the best approach to solve this?

  • Is it possible to relax the AppArmor limitations at runtime? This could work for Tails derivatives but not for Additional Software.


#1 Updated by mercedes508 13 days ago

  • Status changed from New to Confirmed

#2 Updated by sajolida 12 days ago

  • Assignee set to intrigeri
  • Target version set to Tails_3.14
  • Type of work changed from Code to Discuss

mercedes508: Changing this ticket from New to Confirmed move it out of your plate onto nobody's plate, ie. the void. I want an answer to my question, so I'll reassign to the Foundations Team lead.

#3 Updated by intrigeri 12 days ago

  • Assignee changed from intrigeri to sajolida

What would be the best approach to solve this?

Let's check the security impact first so it's clearer if there's a trade-off and what it is: we can't simply make holes in a sandbox without considering the security impact, otherwise we could make the sandbox totally useless without even noticing.

I'm assuming a compromised Tor Browser because that's the threat model in which our AppArmor policy makes any sense at all. Giving access to /usr/share/doc allows enumerating the full list of packages that are installed (every package ships the Debian changelog; we delete these files but leave their parent directory alone; we could delete such empty directories and then the leak won't be the full list anymore, but a subset of it). But we already give access to /usr/share/applications, which allows enumerating another subset of the packages that are installed (those who ship a .desktop file). Both could fingerprint users as running Tails (that's probably a lost cause already in this context) and for those who have installed Additional Software, it could fingerprint them much more accurately.

If we assume that Additional Software is mainly used to install apps that have a .desktop file and their dependencies, then it follows that for the majority of our users, piercing this hole in the sandbox won't leak substantially more fingerprinting info than what we're leaking already. For power users who have all kinds of software in the Additional Packages list, it's a different story. I'm concerned about user fingerprinting in this context because it can lead to more targeted attacks, e.g. against Tails core contributors. Now, we also already allow enumerating fonts, PCI devices, and probably enough other things to generate an accurate fingerprint. So it seems that piercing this new hole would lower the bar for such attacks, rather than make them possible at all.

We could do this. This patch is exported via a rather complicated process so don't bother editing it directly.

  • Is it possible to relax the AppArmor limitations at runtime? This could work for Tails derivatives but not for Additional Software.

/etc/apparmor.d/torbrowser.Browser.firefox could include a .d directory where additional packages could add their local overrides.

#4 Updated by sajolida 9 days ago

Thanks for the detailed answer!

I wasn't sure if it was possible to add local overrides at runtime, but
if this works, then it's a better solution, at least for Whiskers.
We'll try that.

Also available in: Atom PDF