Bug #15725

Are recent Firefox sandboxing improvements worth enabling unprivileged user namespaces?

Added by intrigeri 2018-07-10 15:59:55 . Updated 2018-08-07 09:58:11 .

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

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

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


Subtasks


Related issues

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

History

#1 Updated by intrigeri 2018-07-10 16:15:20

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 2018-07-10 16:15:33

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

#3 Updated by intrigeri 2018-07-10 16:15:46

#4 Updated by Dr_Whax 2018-07-15 22:35:36

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 2018-08-07 09:58:11

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