Project

General

Profile

Bug #15725

Are recent Firefox sandboxing improvements worth enabling unprivileged user namespaces?

Added by intrigeri about 1 year ago. Updated about 1 year ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07/10/2018
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Browser

Description

Some of the recent sandboxing improvements require unprivileged user namespaces to be enabled (+ some AppArmor tweaks): is the risk/benefit worth it?


Related issues

Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 09/02/2017
Blocked by Tails - Feature #15023: Upgrade to Tor Browser based on Firefox ESR60 Resolved 08/30/2017 08/09/2018

History

#1 Updated by intrigeri about 1 year ago

This is not meant to be the unprivileged user namespace bashing festival. It's not in question here that the security history of this feature is doubtful at best. The question is rather whether enabling them in order to get stronger Firefox sandboxing has more advantages than drawbacks. I'm not a security expert and even if I were, I would have no time to conduct a full-blown analysis. Here's some food for thought, mostly to publicize the fact we're asking ourselves this question, and so that people who are better skilled at this than me can get excited :)

The advantages I see:

  • Forbidding network access and restricting filesystem access to the Firefox content processes would be good: it makes it harder to exfiltrate sensitive info.
  • As long as we have no fine-grained D-Bus filtering, our AppArmor sandboxing of Tor Browser is very weak. Forbidding the most risky part of Firefox (content processes) to access e.g. the accessibility bus can make it harder for attackers to have meaningful impact.
  • Maybe we can make our AppArmor policy simpler (aka. less fine-grained) and cheaper to maintain.

The drawbacks I see:

  • Other apps, if exploited, can leverage potentially remaining security issues caused by unprivileged user namespaces to run arbitrary code and quite possibly get root.
  • We already have pretty good filesystem access filtering in place via AppArmor.
  • We could do similarly fine-grained socket access control via AppArmor once we have Linux 4.17.
  • As long as we run X11 and Firefox sandboxing lets the content processes use it directly, meh, perhaps this additional sandboxing does not buy us much. (But once we're on Wayland it's a different story.)

So the way I see it, the trade-off is basically "resist attacks against Tor Browser a bit better" vs. "open ourselves to other attacks vectors". That's tough, uh?

jvoisin, DrWhax: anything to contribute? Anyone else I should ask?

#2 Updated by intrigeri about 1 year ago

  • Blocked by Feature #15023: Upgrade to Tor Browser based on Firefox ESR60 added

#3 Updated by intrigeri about 1 year ago

#4 Updated by Dr_Whax about 1 year ago

intrigeri: I think the subgraph teams might have a strong opinion on this. They designed their oz sandboxing to not use unpriv namespaces, because of that reason.

I'm still researching what they want to do with their "x11 hardening" before I personally will draw a conclusion.

#5 Updated by intrigeri about 1 year ago

intrigeri: I think the subgraph teams might have a strong opinion on this. They designed their oz sandboxing to not use unpriv namespaces, because of that reason.

Yeah, plenty of people made similar decisions a few years ago. I have no idea if they've updated their opinion on this.

Also available in: Atom PDF