[tor-commits] [sandboxed-tor-browser/master] Remove the old and out of date `doc/Architecture.txt` file.
yawning at torproject.org
yawning at torproject.org
Fri Dec 2 05:31:29 UTC 2016
commit f634e86cf37328389d2176dbe084065012954381
Author: Yawning Angel <yawning at schwanenlied.me>
Date: Fri Dec 2 05:30:01 2016 +0000
Remove the old and out of date `doc/Architecture.txt` file.
Better documentation is at:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux
---
doc/Architecture.txt | 160 ---------------------------------------------------
1 file changed, 160 deletions(-)
diff --git a/doc/Architecture.txt b/doc/Architecture.txt
deleted file mode 100644
index 0a5c789..0000000
--- a/doc/Architecture.txt
+++ /dev/null
@@ -1,160 +0,0 @@
-sandboxed-tor-browser Architecture And Design
-Yawning Angel (yawning at schwanenlied dot me)
-
-[Note: This started out as part of an e-mail thread with the Tor Browser
- developers.]
-
-Design requirements:
-
- * Modern Linux kernels without USER_NS support MUST be capable of
- supporting the sandboxed tor browser (basically, use bubblewrap
- since it's less of a monstrosity than firejail is, both require
- SUID root or additional capabilities for this use model which
- complicates the installation process, but that's an orthogonal
- issue).
-
- bubblewrap packages are available for Debian and Ubuntu which probably
- covers the bulk of the user-base, though I am doing development on
- neither.
-
- * Proxy bypass MUST BE impossible without a sandbox escape, even if
- the adversary gets RCE capability. This is harder than it appears,
- and influences a few other thoughts.
-
- * The firefox process's write access to the filesystem MUST be limited
- to the user preferences, download directory and the bookmarks. The
- firefox process's read access to the filesystem SHOULD be limited to
- the Tor Browser bundle installation directory.
-
- There is a UX tradeoff here in that, without access to at least the
- user's home directory, uploading things is difficult, but there's a
- lot of data a potentially malicious firefox executable can get at
- if it can read from the entire home directory.
-
- * The firefox process MUST NOT be responsible for launching the tor
- instance. The tor process MUST live in a separate sandbox, with no
- access to user data (ie: tor MUST only be able to see
- Browser/Tor-Browser/Data).
-
- * The firefox process MUST NOT be responsible for updating Tor Browser.
- The downloads MUST be fetched over tor, and a more permissive
- sandbox spawned to handle updating.
-
- * I have no idea how to handle meek, I sort of don't care for the
- 0.0.1 non-shit sandbox implementation. Something to keep in mind.
-
- * Audio is a mess. If the host system has PulseAudio, it can optionally be
- exposed in the sandbox, but that is another attack vector.
-
- * This really needs Wayland, because the X11 security model is a
- shitfest of total fail, and "firefox owned the X server and got out"
- is a distinct possibility.
-
-Design:
-
-sandboxed-tor-browser is a Go application that handles:
-
- * Downloading and installing Tor Browser.
-
- * Fetches and installs the latest Tor Browser over Tor, or the normal
- internet, depending on of Tor is already running as a system service.
- * The TLS cert for the download metadata fetch (`downloads.json`) is
- validated via static HPKP pins. The actual downloads can come from
- anywhere (allowing the possibility for CDNs/mirrors).
- * Validates the PGP signature with a hard coded copy of the PGP key.
-
- * Running a sandboxed instance of the tor daemon.
-
- * Launches the bundle's tor daemon inside a sandbox.
- * A seccomp whitelist is used unless pluggable transports are enabled, in
- which case a blacklist is used.
- * This process has full network access, but an extremely limited view into
- the host filesystem.
- * For the initial release only pluggable transports supported by obfs4proxy
- are enabled.
- * Libraries are handled in a similar manner to how they are for the firefox
- container (as in, only what is needed, nothing more).
-
- * Updating Tor Browser.
-
- * Version check over Tor on launch. Static HPKP pins are used to ensure
- the remote update metadata server is trusted.
- * Download MAR format updates over Tor.
- * Validates the MAR signature with hard coded copies of the MAR signing
- key(s).
- * Apply the MAR updates using the `updater` excutable shipped with Tor,
- supporting both incremental and complete updates. This process is in a
- sandbox that does not allow external network access at all.
-
- * Run a sandboxed instance of Tor Browser.
-
- * A LD_PRELOAD stub is used to force firefox to use AF_LOCAL sockets for
- the control and SOCKS ports, and to work around certain Firefox quirks
- and bugs.
- * Uses bubblewrap to instantiate a Linux container.
- * seccomp2 system call filter, with whitelist/blacklist format that is
- compatible with Subgraph.
- * Separate PID table, mount table, etc.
- * No external communication except via stdio, and path based AF_LOCAL
- sockets.
- * Normalized hostname, `/etc/passwd`, `/etc/group`, D-bus machine ID.
- * Limited view of the host filesystem, all directories read-only unless
- * otherwise specified. The sandboxed filesystem layout is normalized
- as much as possible.
- * System libraries are explcitly bind mounted into the container in
- standardized locations to reduce attack surface and to make it hard
- to use the installed libraries to gain much insight into the host
- system. This is accomplished via reading the ELF dynamic section of
- the binary to be executed, and then mounting a breadth-first-search
- with the assistance of the `/etc/ld.so.cache` file.
- * Gtk Theme related directories.
- * The X11 AF_LOCAL socket.
- * (Optionally) The PulseAudio socket.
- * The browser directory.
- * The browser caches directory (read/write, might be removed).
- * The browser profile directory (read/write, extensions sub-dir
- read-only unless overriden by the user).
- * The browser downloads directory (read/write)
- * The browser desktop directory (read/write)
- * A runtime directory.
- * A surrogate control port that gives "fake" responses to Tor
- Browser. The bare minimum to get a fully functional circuit
- display is implemented, and the surrogate ensures that responses
- are filtered appropriately so that Tor Browser never sees streams
- or circuits that it is not responsible for.
- * A re-dispatching SOCKS proxy, required to identify which streams
- and circuits should be visible to the control port surrogate.
-
-Sandbox weaknesses:
-
-Basically sandbox escape should require one of a kernel exploit, display server
-exploit, or Tor SOCKS port based exploit in addition to the Firefox exploit, so
-from a security standpoint things are vastly improved.
-
- * (Security, Privacy) X11 is a huge mess of utter fail, especially
- considering the sandboxed processes get direct access to the host X server.
-
- * Vector for sandbox escape or exploits.
- * X processes can easily become display server wide keyloggers and other
- things that threaten user privacy.
- * Certain applications set X root window properties that leak information
- about the host system (eg: PulseAudio).
-
- Using a nested X solution such as Xephyr "just works", so that's a way to
- mitigate this for those that want that.
-
- * (Security, Privacy) If the user opts to enable PulseAudio support, it opens
- up another attack vector for exploits, government ultrasonic mind control,
- the browser acting as a listening device, and etc.
-
- * (Security, Privacy) Firefox requires a `/proc` filesystem, which contains more
- information than it should have access to.
-
- * (Security) The Firefox process can write bad things to the profile
- directory if it choses to do so.
-
- * (Privacy) The Firefox process still can access the network over Tor to
- exfiltrate data.
-
- * (Privacy) While the user name is re-written in the sandbox to
- `amnesia`, the UID/GID are not.
More information about the tor-commits
mailing list