Project

General

Profile

Feature #16432

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

Added by sajolida 3 months ago. Updated 8 days ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
02/07/2019
Due date:
% Done:

0%

QA Check:
Info Needed
Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

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: https://gitlab.com/scif/whiskers/issues/95.

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.

torbrowser.Browser.firefox.patch View (478 Bytes) sajolida, 04/06/2019 11:04 AM

torbrowser.Browser.plugin-container.patch View (440 Bytes) sajolida, 04/06/2019 11:04 AM

History

#1 Updated by mercedes508 3 months ago

  • Status changed from New to Confirmed

#2 Updated by sajolida 3 months 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 3 months 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 2 months 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. https://gitlab.com/scif/whiskers/issues/105.

#5 Updated by sajolida 19 days ago

I tried using a .d directory to allow Whiskers to add a local override.

I'm adding an include to both /etc/apparmor.d/torbrowser.Browser.firefox and /etc/apparmor.d/torbrowser.Browser.plugin-container. See patches in attachment.

My proof-of-concept is explained in more details on https://gitlab.com/scif/whiskers/issues/105.

Would this work for you?

Then I'll have to figure out how to update the profiles when installing the whiskers Debian package and we'll be good to go.

#7 Updated by intrigeri 8 days ago

  • Assignee changed from intrigeri to sajolida
  • QA Check changed from Ready for QA to Info Needed

Hi sajolida!

So this ticket is about two things:

  • Allow Tor Browser to view other HTML files in /usr/share/doc: do we want that? I'd rather not do this upstream nor in Debian, but we could do this as part of the Tails delta.
  • Allow packages to extend the Tor Browser's AppArmor policy via drop-in snippets: my understanding is that the only concrete incentive we had to do so is now obsolete so I'll assume it's not worth our time at the moment.

#8 Updated by sajolida 8 days ago

  • Status changed from Confirmed to Rejected
  • Allow Tor Browser to view other HTML files in /usr/share/doc: do we want that? I'd rather not do this upstream nor in Debian, but we could do this as part of the Tails delta.

I don't think that our personas would go look for HTML pages in
/usr/share/doc if they need some doc about some specific (possibly
additional software) and would rather look for it online.

So I don't think we should spend time on this for now.

  • Allow packages to extend the Tor Browser's AppArmor policy via drop-in snippets: my understanding is that the only concrete incentive we had to do so is now obsolete so I'll assume it's not worth our time at the moment.

Agreed.

I'm still happy I touched AppArmor profiles for the first time but I'll
reject this ticket for now :)

Also available in: Atom PDF