[tbb-dev] Sandboxing Tor Browser - A New Beginning (?)

Tom Ritter tom at ritter.vg
Thu Jul 5 18:46:21 UTC 2018


On 3 July 2018 at 18:03, Matthew Finkel <matthew.finkel at gmail.com> wrote:
> Hi All,
>
> This is the beginning of a conversation about creating a plan for moving
> towards sandboxing Tor Browser on every platform.


Thanks for this Matt!  I started typing and kept typing and just kept
typing and well... sorry.


> Over the last few years,
> there existed a Sandboxed Tor Browser on only Linux[0] (created and maintained
> by Yawning Angel). However, Tor Browser aims at providing a Private Browser on
> all supported platforms (Microsoft Windows, Apple Mac OS X, GNU/Linux, and
> Android (AOSP))[1][2], this means we must provide a sandboxed run-time environment on
> all platforms.


For the benefit of others reading tbb-dev, I want to explain the
difference between the 'Content Process Sandbox' and the 'Parent
Process Sandbox'.  This is intended to answer confusion like "Chrome
is sandboxed.... isn't Firefox sandboxed? I thought I saw some stuff
in the release notes about it?"

Firefox (and Chrome, and Edge) have a parent process that executes
multiple child or 'content' processes. (It also executes other helper
processes like a Web Extensions process and a GPU process on some
platforms.)  The content process is responsible for parsing HTML,
rendering it, executing javascript, running the javascript JIT, etc.
The parent process does the actual TLS handshakes, HTTP conversations,
renders the browser UI (and composites the page contents I think but
I'm not sure on that), and some other stuff.

Firefox has been working on a restrictive sandbox for the Content
Process for the past few years. We've got a Mac sandbox that can only
be tightened a small amount more. Our Windows sandbox is pretty good
but is missing one large attack surface reduction called 'win32k.sys
lockdown' that is blocked on ~1 year of clock time worth of graphics
refactoring. I'm unsure of the relative strength of our Linux sandbox,
but I think it's fairly good if you exclude stuff like "The X11
protocol lets you do pretty crazy things and we need to lock that
down".


Firefox has not done any work on sandboxing the parent process. All
the discussions I have with folks at Tor are about protecting the
parent process for additional defense in depth. Thus we're assuming
that a) An attacker has exploited the content process but cannot
achieve their goal from that position and b) decides to attack the
parent process.

Both of these assumptions are not necessarily true, and thus means we
need to address the opposite of those assumptions _too_; and we should
prioritize that work in relation to the larger architectural goal of
"How do we sandbox the parent process".



To the point of (b): This document focuses on sandboxing as supporting
the goals of the design doc, which I think is a fine approach. But we
should be aware of other approaches to evaluating sandboxing and one
is from the capability reduction standpoint. A lot of sandbox escapes
today occur by getting code execution in the content process and then
exploiting the kernel. So identifying the features on each platform
that can reduce kernel attack surface, and then seeing what prevents
us from using these features (starting in the content process but
eventually including the parent process) would be a worthwhile
exercise.  Similarly to focusing on the kernel, we can look at what
others permissions are needed (by the content and eventually the
parent) and determine which ones are the scariest and work to either
remove them entirely, or move them to a separate process.


To the point of (a), we should consider what goals an attacker has
when exploiting Tor Browser. Enumerating attacks is likely to miss
some, but not considering attacks means we're trying to defend
ourselves from 'everything' with no priority. I think I would classify
attacks into High Impact and Opportunistic Impact, and focus
specifically on "code execution achieved through an exploit" (and not
things like 'exploiting' a fingerprinting vector we have not solved in
the web platform.) We may miss some attacks; but the ones we can list
today are, I think, accurate in their impact.

High Impact goals are ones that do one or more of the following:
achieve a proxy bypass, temporarily corrupt's tor's configuration
leading to a direct-to-relay connection (by changing the user's
bridge/guard/DirAuths), permanently corrupts the user's machine (by
installing malware or affecting tor's configuration), or (less bad
without a proxy bypass but still bad) retrieves an identifier that
uniquely and persistently identifies a user (MAC address, serial) and
exfiltrates it.

Opportunistic goals are ones that compromise the browser process as it
currently runs (without persistence) and rely on the user performing
an action using the browser that discloses information. For example,
reading other websites cookies is only useful if the user is active on
other sites in a way that identifies them.



When one is able to achieve High Impact goals from the Content Process
- it seems to me that engineering effort should be focused on closing
_those_ holes first, before trying to build a solution for the parent
process. (I'm not saying we shouldn't plan for the parent process
though!)




I could talk more about what actions an attacker can perform if they
exploit the Content Process (both currently and post-Fission
https://wiki.mozilla.org/Project_Fission ) and how they can attack the
Parent Process; but I'm going to skip that for now; but would be happy
to do so if it seems helpful.



> Unfortunately, each operating system provides a unique set of
> sandboxing techniques and capabilities, so we must work with the facilities we
> are given. In some cases, we may need to be creative about how we achieve our
> goals.
>
> I do not have all the answers, and there are some open questions below.
>
> On Windows, we have the Windows integrity mechanism[3], Windows Containers[4],
> SetProcessMitigationPolicy[5], App Container[6], and maybe some others. Some
> of this functionality is already used by Firefox.

For Windows Container I found the following helpful reading:
https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/

In particular, they require Windows Server or Windows 10 Professional
or Enterprise. Containers are awesome, and in particular Hyper-V based
containers are essentially Virtual Machines with their own kernel and
therefore we could do really powerful things with them. But I think we
need to wait a few years until it becomes more widely available.

There's https://www.bromium.com/ which operates in this space, and
despite having a bunch of slick marketing and buzzwords and stuff
actually has a really powerful technology core.


App Container is primarily for Windows Store apps, but can also be
used for 'Legacy Apps' per
https://docs.microsoft.com/en-us/windows/desktop/secauthz/appcontainer-for-legacy-applications-
. I can't quite tell how useful it is.

The Chromium/Firefox sandbox on Windows is composed of the interaction
of SetProcessMitigationOptions (of which there are many options),
Integrity Level (both an 'Initial' and a 'Delayed') as well as Job
Level, Access Token Level, Alternate Desktop, and Alternate Windows
Station.


> On Mac OS X, there are two sandboxing techniques available. The first is
> Seatbelt[7]. Apple deprecated it in favor of code signing entitlements[8].
> Unfortunately, the code signing entitlements are not as fine-grained as
> those Seatbelt provides, but we can enable different entitlements per
> "target"[9]. I don't know if this will be difficult for us. Therefore, we
> should utilize the code-signing restrictions where they are appropriate, but
> we should follow Safari[10], Chromium[11], and Firefox[12][13] by applying
> restrictive Sealtbelt policies where applicable.

Can you apply both Seatbelt and Code Signing Entitlements?

Also; have you experimented with/confirmed the restriction mentioned
at All Hands; that a process with a Seatbelt Policy cannot launch a
process with a more restrictive seatbelt policy?  (I think mcs ran
into this with the Mac Sandbox policy that used to ship with Tor
Browser Alpha.)  This is a significant problem to any Apple-based
sandboxing policy, and frankly one I think someone should make a
semi-organized petition from browser makers to Apple to fix.

Additionally; OSX 10.14 Mojave provides new sandboxing features;
including ones that feature-match Microsoft's Arbitrary Code Guard and
Code Integrity Guard. I don't know much about these; but they are
powerful and in the future, Mozilla will probably be interested in
them. (Future being 1-2+ years from now.)


> On GNU/Linux, we can use the namespacing and secure computing (Secure
> Computing) facilities in the kernel exposed to userspace. Sandboxed Tor Browser
> on Linux already shows how these can be combined and form a sandbox. In
> particular, we can use bubblewrap[14] as a setuid sandboxing helper (if user
> namespace is not enabled), if it is available. In addition, we can reduce the
> syscall surface area with Seccomp-BFP. CGroups provide a way for limiting the
> resources available within the sandbox. We may also want to manually
> proxy/filter other system functionality (X11).
>
> Last, but not least, on Android, we begin with a fairly strict sandbox provided
> by its permissioning model[15], distinct per-app users, and SELinux policies.
> Because every app is run using a distinct user, and each has its own storage
> directories, we get Linux's DAC on the file system for "free". In addition, we
> can use some of the same techniques available on GNU/Linux on Android, namely
> the seccomp-bpf and namespaces, if they are available. Android provides
> privilege and permission isolation within an App by using Services. With some
> refactoring, we can isolate some parts of Firefox into isolated permissionless
> services[15].

Something else to consider is how each of these sandboxing
technologies (on each platform) are enabled. Some are applied at
runtime by the process, the process starts more privileged and then
drops privileges. Others are applied by the OS before execution, and
the process never has the elevated privileges.

If a process needs to do something that the sandbox should prevent -
like creating a socket connection to another process - there are two
ways (I think only two) to achieve that goal.  The first way is a
process that _has_ permission gives a resource (like a socket
connection) to the restricted process. The second way is the
restricted process starts with less restrictive permissions, does the
privileged action (like creating a socket) and then applies the
sandbox (entire in whole or an additional component of it) to itself -
ideally before processing any user input that could be malicious.

I think there's a lot of focus in this document on applying sandbox
policies by the OS before/as the process starts and not following the
'drop privileges' model. But dropping privileges is much more
flexible. I think some confusion with this model is the notion that
the process is 'sandboxing itself' and of course one can't trust a
process that is simultaneously compromised and attempting to perform
security operations so that model must be broken - but this notion is
incorrect. The process - before it is able to be compromised by
attacker input, before it processes anything from the web - instructs
the OS to apply the sandbox to itself, and cannot later opt-out of
that restriction. It's true that something could go wrong during the
sandbox application and result in a the process staying elevated - but
I think that is easy to code defensively for and even test at runtime.



> I'll begin by describing the goals, as I see it, for sandboxing Tor Browser.
> Hopefully, this will help us evaluate the different available techniques. These
> goals are derived from the Design document[16] and are the means for archieving
> Tor Browser's end-goal.
>
> In particular, the sandboxing techniques preserve the Security Requirements of
> a private browser when the browser, itself, fails at maintaining those
> criteria. By this I mean the sandbox should be designed such that if the
> browser process loses any of the Security properties (through a logical bug,
> exploited vulnerability, etc), the sandbox provides an additional layer of
> those properties and the user is not in immediate danger. The sandbox may, in
> some situations, improve the Privacy properties of Tor Browser, for example if
> a component/device is emulated instead of providing the browser with raw
> access. We should use these mechanisms when they are available.
>
> 1) Proxy Obedience
> 2) State Separation
> 3) Disk Avoidance
> 4) Application Data Isolation
> 5) Secure Updating
> 6) Usable
> 7) Cross-Origin Fingerprinting Unlinkability
>
> We'll go through these one-by-one and describe the role of a sandbox and how we
> can achieve this on each platform.


Yes; but I would phrase things differently.  I also want to call out
our strengths and weaknesses.

Our goals, as I understand them, are twofold:
1) Improve the sandboxing of the browser as a whole to a higher level
to i) reduce attack surface from vulnerabilities and common attacker
positions and ii) to act as a safety net for design doc goals
2) Eventually, eliminate Tor Browser as a fork of Firefox. What this
means in detail is (to me at least but probably everyone) not fully
determined, but I'll assume a world where there's at least the window
of branding changes, pref flips and system-like addons but no
functionality patches...

Our strengths, as I see them:
1) We are privacy research experts
2) We're willing to compromise on user freedom, web features, and
performance for security and privacy
3) We're willing to experiment with more complicated user interfaces
4) Our use case for the browser is (probably) different. We're
(probably) not seeing long lived browser sessions and therefore have
more frequent restarts. We're (probably) not seeing a lot of logged in
sessions, so restarting the browser (especially with an
open-tabs-restore feature) is not as painful.

Of course we want our browser to be usable, so we're not going to go
crazy on (2) or (3), but that we allow the user to disable JavaScript,
and have and expect to keep a 'security slider' are examples of where
we're willing to go.

Our weaknesses, as I see them:
1) We're tracking ESR for now
2) Un-upstreamed patches are painful for us
3) We are not well suited to undertake large browser architecture
projects, especially if it diverges from Firefox
4) We are neither browser architecture experts, nor sandboxing
experts. In particular this makes us ill-suited to predict feature
breakage or performance degradation from a hypothesized
sandbox/architecture change.


In particular, while looking at this, I think this gives particular
weight to aligning ourselves with future Firefox plans. And that we
can often begin adopting those plans before Firefox does.



> Note, this design assumes a launcher-based
> sandboxed architecture (similar to the Sandboxed Tor Browser on Linux):
>
>                       ------------------
>                       |    Launcher    |
>                       ------------------
>                               |
>                               |
>                  ------------------------------
>                  |            |               |
>                  |            v               |
>                  |     ----------------       |
>                  v     |  Sandbox    |        v
>     -----------------  | ----------- |    -----------------
>     |   Sandbox     |  | | Broker  | |    |   Sandbox     |
>     | ------------- |  | ----------- |    | ------------- |
>     | |  Firefox  | |  ---------------    | |    Tor    | |
>     | ------------- |------/    \_________| ------------- |
>     -----------------          Controller -----------------
>             |____________________________________|
>                          Proxy IPC
>
>
> Note, the sandboxed broker process (or processes) moves some functionality from
> the launcher process into a child process. This process is not as heavily
> sandboxed as the Firefox and Tor process, but, for example it would not need
> networking. This process would handle sending NEWNYM, provide a circuit display,
> change bridge configuration (general controller functions). In addition, it would
> handle copying files into and out of the Firefox sandbox, as an example.
>
> Unfortunately, there is not an existing cross-platform solution for this design.
> We can take bits-and-pieces from other solutions, creating this will require
> engineering effort.


As a nit, this diagram shows all the processes as being 'enveloped' by
a sandbox; but that illustration is misleading if one is using, e.g.
Seatbelt on Mac. It's more accurate that the process is named
Sandboxed-Tor or something like that, rather than depicting some
additional 'thing' (which appears to be a process) that 'is' the
sandbox. This illustration makes it look more like you're running
stuff in a container. (Which may actually be the case for some
platforms though.)

Also: I think the IPC diagrams of Firefox <-> Tor are accurate; but we
leave out the Content Processes in this illustration.  If in the
future Mozilla or Tor separates browser functionality into a helper
process to reduce privileges in the Content or Parent process, it
becomes possible that that helper process (a child of 'Firefox') will
communicate with the Broker (and Tor).  For example if/when Necko
leaves the parent process and all network operations happen in a
helper process off Firefox.


Finally and most substantially, I want to think about the assumption
you're making about a launcher process. I agree entirely that we want
our parent-process-is-sandboxed end-goal to look logically like your
diagram during operation. Firefox can't talk to the network or Tor's
control port: it talks to a broker that talks to Tor's control port
and it talks to Tor for SOCKS proxying using a Named Pipe or Domain
Socket. Certain operations are also relegated to the Broker and
Firefox can't perform them.

But getting to that state... Using a Launcher process is one solution;
but it's not the only solution. So I think we should keep that in mind
and not assume a launcher process; but instead plan for a logical
run-time design of:

     +-------------------+
 |-|-| Sandboxed-Firefox |------------
 | | +-------------------+           |
 | |                                 |
 | | Primary (Existing) Browser IPC  |
 | |                                 |
 | | +-------------------+           |
 | --|     Sandboxed     |- |        |
 |   | Content Processes |  |        |
 |   +-------------------+  |        |
 |                          |        |
 | TBD IPC          TBD IPC |        |
 |                          |        |
 |   +-------------------+  |        |
 |---| Other Sandboxed   |--|        |
 |   | Helper Processes  |  |        |
 |   +-------------------+  |        |
 |                          |        |
 |   +--------------------+ |        |
 |---|     Sandboxed      |-|        |
   |-| Networking Process |          |
   | +--------------------+          |
   |                                 |
   |                     Tor Control |
   | SOCKS over Domain      Requests |
   |   Socket/Named Pipe             |
   |                                 |
   | +--------------------+          |
   | |  Sandboxed Broker  |----------|
   | +--------------------+
   |                    | Filtered Control Requests
   | +--------------------+
   |-|    Sandboxed Tor   |
     +--------------------+

Spelled out:
 - The FF Parent Process talks to and controls the Content Processes
(using existing IPC mechanisms) and maybe/probably interfaces with the
Networking process and other Helper Processes in unknown future ways.
The content processes probably talk to the Network process directly,
they might also talk to the other helper processes.
- The Networking process talks to Tor using SOCKS with (probably) a
domain socket or named pipe
- Tor Control requests are sent from the Parent Process to the broker
which filters them and then passes them to Tor over the control port.
- The broker is most likely the least sandboxed process and may
provide additional functionality to the parent process; for example
perhaps it passes a writable file handle in a particular directory so
the user can save a download.


I think we should plan on creating a proof of concept toy program on
all platforms that mimics the process execution and mitigations. (I
once started one of those here:
https://github.com/tomrittervg/sandboxsandbox/blob/master/SandboxSandbox/SandboxSandbox.cpp
) This will allow us to experiment/assert with certainty about what
operations are allowed and disallowed and allow easier code review and
experimentation by individuals especially those looking at their
platform outside their area of experience. It's also lower cost that
trying to implement it in FF from the get-go.


> 1) Proxy Obedience
>
> The last line of defense against a proxy-bypass is a mechanism for dropping all
> outgoing IP packets from the browser that are:
This wi>   - not TCP
>   - or TCP but not destined for the Tor proxy port (SOCKS or HTTP)
>   - or all packets (including TCP) if the proxy listener is not a TCP port
>     (Unix domain socket, named pipe, etc)

Dropping implies the packets are sent from the process and then
dropped by the OS. This is not always the case, on Windows (with
user_restricted) and Mac at least, the process is just outright
prevented from making successful network calls.

> We should also consider guarding the creation of all non-Unix domain sockets
> and non-named pipes with a pref. I believe sandboxing should be optional, but
> enabled by default (at least with first few versions), so excluding that code
> at compile-time is not an option.  However, a pref-guard only stops unintended
> proxy-bypass through normal control flow. This only slightly increases the
> difficulty of some exploit methods.

I agree that a pref-based solution is only actually useful for testing
purposes and doesn't provide security.

> Per-platform sandboxing techniques:
>   a) Microsoft Windows
>     i) Windows 8+
>       If the user can elevate for administrator permissions, then the launcher
>       can:
>         - install a network filter using the Windows Filter Platform[17]. This
>           can deny any connection from any process (based on the process's
>           fully-qualified file name)[18]. This adds some risk because if the
>           launcher process exits unexpected for whatever reason, the firewall
>           rule may remain in place.
>     ii) Windows 10
>       We can create a new network namespace[19] using the (undocumented) HNSCall
>       procedure[20]. This is very appealing.

I think this is only possible if you're using a version of Windows
which supports containers, which most of our users won't have.

>     iii) Windows 7+
>       If the platform is Windows 8+ and the user cannot elevate to
>       Administrator or if the platform is Windows 7:
>         - TODO: can/should we use DLL injection of WinSocks and manually
>           filter all proxy-bypass network connections?

I would expect we could use the same type of shims the content process
currently uses to achieve this goal.

> Is there something we
>           can use for mitigating ROP gadgets within the sandbox?

I'm not sure where this goal came from, but it seems very independent
of sandboxing. But I think the general answer is: No, not until one
has or can emulate Execute-Only memory, which might be possible if one
runs their own hypervisor (I don't think Hyper-V can do it but maybe?)


Back to networking: I think you missed the most straightforward one:
the USER_RESTRICTED token level which blocks networking.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1403931 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1177594

>   b) Mac OS X
>     i) We can restrict network access using the
>        com.apple.security.network.client and com.apple.security.network.server
>        entitlements[21].
>     ii) We can further restrict which types of connections the browser is
>        allowed. Previously, there was a seatbelt profile for Tor Browser[22],
>        but it is not usable with newer versions of the browser. We can
>        continue using it for only allowing access requests for Unix domain
>        sockets, and denying all other network connections.

Note that the content Sandbox for Mac already enforces networking restrictions.

>   c) GNU/Linux
>     i) On Linux, significant progress was already made in terms of sandboxing
>        Tor Browser. There are two methods we can use:
>          - Isolated network namespace via bubblewrap[14]
>          - Seccomp-BPF on socket syscalls
>     ii) If bubblewrap is not available, we can fallback on using unshare if it
>         is available and user namespace is enabled
>     iii) If user namespaces are not avialable, we ask the user for elevated
>          privileges and manually fork into the new network namespace
>          (worst-case).
>
>   d) Android
>     i) We can use the same (or similar) Seccomp-BPF filter that we use on Linux
>     ii) We can move the Gecko service into an isolated process without any
>         permissions (including Networking).
>     iii) If all networking goes through Necko, and Neck is in the isolated
>          process, then the remaining code, outside the isolated process, should
>          be proxy-safe or it is the tor process.


As with all things sandboxing, we need to be sure there are not IPC
mechanisms to a privledged process that bypasses the sandbox
restrictions. On the networking side, there is
https://searchfox.org/mozilla-central/source/dom/network/PUDPSocket.ipdl
- which i think is used by WebRTC.


> 2) State Separation
>
> Per-platform sandboxing techniques:
>   a) Microsoft Windows
>     i) I'm not sure if there is more we can do here.
>
>   b) Mac OS X
>     i) The Seatbelt profile[22] can restrict access to all other Firefox
>        profiles
>     ii) The Seatbelt profile can only allow access for bundled libraries
>     iii) We may exclude entitlements for most system services
>
>   c) GNU/Linux
>     i) We can create new IPC, mount, and uts namespaces
>     ii) We can provide a clean environment
>     iii) The new mount namespace contains only the required bundled libraries
>          required for running
>     iv) D-Bus/I-Bus access would be nice, if we can do it safely.
>
>   d) Android
>     i) All apps are isolated by default, so there should never be shared state.
>     ii) Ensure we have the smallest set of intent filters we need
>     iii) Ensure we have the smallest set of exported components we need
>     iv) Ensure we have the smallest set of broadcast receivers we need
>     v) Ensure we only use Broadcast intents where it is necessary
>     vi) Is there something else we should investigate here?

Why is there so much difference between the other OSes and Windows?

The goal for State Separation, as I understand it, is to ensure that
no existing browser settings/profiles/plugins are used in Tor Browser.
I think there would be two reasons this could happen:
a) The browser itself has a bug that we should fix, where it loads
some existing data
b) Some third party utility has installed something into Tor Browser

(b) seems generally unmitigatable. For (a) the primary mechanism to
prevent this is "don't have browser bugs". The sandbox's role is "If
there is a browser bug, block it from trying to read and use that
data."  So anything we can do in any sandbox to restrict access to
existing user data or system directories would support this goal.

> 3) Disk Avoidance
> In general, I'd like #7449 mitigated.
>
> Per-platform sandboxing techniques:
>   a) Microsoft Windows
>     i) Windows 10+
>       - On very recent versions of Windows, we can create temporary filesystem
>         Layers[23][24]. I'm not sure if these are memory-backed or
>         filesystem-backed.
>       - We can create a read-only layer over the installation directory
>         - #18367 may be useful (side-by-side user/app data on Windows)
>       - Can we can isolate the container from system services?

Again, non-consumer versions of Windows only.

>   b) Mac OS X
>     i) We can use entitlements[25]
>     ii) The Seatbelt profile[22] provided additional access restrictions.
>     iii) Is there a filesystem layering mechanism available in OS X (like tmpfs in Linux)?
>       - Specifically, if we can use this for ~/Library/Caches/TemporaryItems and ~/Downloads
>
>   c) GNU/Linux
>     i) We can create new IPC, mount, and uts namespaces
>     ii) #18369 may be useful (side-by-side user/app data on Linux)
>
>   d) Android
>     i) The app is self-contained by default
>     ii) Need #26574
>     iii) Additional auditing required

What about restricting write access to temp directories?  That seems
like the quickest and most compatible option (although it wouldn't
catch every possible occurrence of this issue.)

In general, similar to State Separation; I think there's two
categories of issues here:
a) Things the browser does that are browser bugs
b) Things the OS does independent of the application

A sandbox can provide a safety net for things in (a).


> 4) Application Data Isolation
> I'll claim the per-platform sandboxing techniques are the same as Disk
> Avoidance.

I think this one is even easier, since one can simply prevent write
access to any directory except the containing one. This would have to
come at the cost of additional engineering to change how the File Save
dialogs work though - or you'll have a lot of confused and upset
users.

> 5) Secure Updating
> Nearly the same sandboxing techniques can be used on all platforms. A
> launcher-component (maybe not the launcher, but a reduced-privileged process,
> not the browser) downloads the update. Next, on download completion, a
> launcher-component verifies the download and installs it (I can't justify
> verifying the download in an unprivileged, sandboxed process - I'd like to do
> it, but I don't see a benefit).
>
>   a) Microsoft Windows
>     i) Layer read-only filesystem on top of install dir, prevents presistant
>        modifications
>
>   b) Mac OS X
>     i) Seatbelt profile prevents write access of app binaries
>
>   c) GNU/Linux
>     i) Mount namespace provides read-only access of install dir
>     ii) Mount namespace does not include launcher binaries
>
>   d) Android
>     i) If App was installed using a App Store, then that is responsible for
>        updating
>     ii) If the app was installed by the user (side-loaded), then the we can
>         isolate downloading into a separate process, and then verification
>         can be handled in an isolated process. Finally, the Android Package
>         Manager controls installing the update.

This one is at odds with (4) which says "You're not allowed to write
anything outside your install directory."  We need to be more explicit
about what parts of the install directory one is allowed to write to.

Web Extensions come into play here. And themes. If we want to allow
them; we need to carve out exceptions for them.  And ideally we would
use the sandbox to enforce an additional safety net against system
add-ons if that's possible (e.g. they're not installed into the same
place as web extensions.)


> 6) Usable
>
> Unfortunately, despite the above suggestions, this sandboxing model fails if
> users find its unusable. In particular, with temporary file systems, we should
> provide a method for safely extracting a file from the temporary location and
> copying it to a permanent location using the launcher process.

I would argue that this extraction should be automatic. Anything else
is unusuable. Users won't be used to being unable to save downloaded
files whereever on their system they want; adding another thing on top
of that would be too painful.

> In addition,
> exposing operating system functionality which may be fingerprintable and/or
> another attack vector should be optional if it unbreaks the web (such as
> providing pulseaudio on Linux[26]). As usual. we must be careful about
> giving users too many customizable switches.

Yea; this one is tough.

> 7) Cross-Origin Fingerprinting Unlinkability
>
> I've less experience here on non-Linux OS (and Sandboxed Tor Browser is
> already a good base on Linux). Which other components should we consider
> spoofing (if possible) or go out of our way and disallow access (if not
> possible using the above means)?


So the Browser already brokers access to features on the Web Platform
and can be thought of (and really is) a 'sandbox' for webpages. You're
only fingerprintable based on what the Web Platform provides. If it
provides something fingerprintable; we need to either fix that
fingerprint or block access to it at that layer.

I would argue that the role sandboxing should provide here is
fingerprinting protection in the face of code execution in the content
process. Assume an attacker who has a goal: identify what person is
using Tor Browser. Their actions are going to be goal oriented. A
website cannot get your MAC address. But if a website exploits a
content process and is evaluating what is the best cost / benefit
tradeoff for the next step in their exploit chain: the lowest cost is
going to be 'zero' if the content process does not restrict access to
a OS/computer feature that would identify the user.

So the goal of sandboxing in this area would be to restrict access to
any hardware/machine/OS identifiers like OS serial number, MAC
address, device ids, serial numbers, etc. After that (the 'cookies' of
device identifiers if you will), the goal would be to restrict access
to machine-specific features that create a unique fingerprint: like
your GPU (which I illustrate because it can render slightly unique
canvas data) or your audio system (which I illustrate because it can
apparently generate slightly unique web audio data.)



-tom


More information about the tbb-dev mailing list