[tbb-dev] Sandboxing Tor Browser - Next Step

[Yawning Angel]

On 07/30/2018 01:39 PM, Arthur D. Edelstein wrote:
> > a) one standard VM on all desktop OSes running Tor Browser on Linux
> > b) Per-OS container/virtualization solution
> > c) No container/vm, but sandboxing the parent and content
> >    processes using OS-specific mechanisms (dropping privs etc.)
> > d) a mix of all options choosing the best per platform

The correct answer is "d", with Linux taking the "b" route.

> Option (a) seems like a radical and difficult approach, but I do think
> it's worth thinking about a little more anyway. Suppose we were forced
> at gunpoint to implement (a). Could we make it work? How bad would it
> be? Are there big benefits?

It could be made to "work", but it would be fairly horrible:

 * On potatoes pretending to be computers.
 * For people that have limited bandwidth to download a full VM image.
 * The UI/UX will be a nightmare to get right (How will files work?)
 * Updates would be a nightmare to get right.

If people are unconvinced about this, they are welcome to find a
suitably low end potato (eg: an Atom netbook with 1 GiB of RAM), and use
Tails in Virtual Box on Windows as as their sole Web Browser for a week.

> 2. Yawning's Sandbox: Should we try to get Yawning's sandbox
> production ready? (By "production ready" I mean: bundled with the
> default Tor Browser download, requiring no user intervention to work,
> and retaining all existing features.) There's a lot to be said for
> using something that already exists instead of starting from scratch.
> Getting something in the hands of users on one platform ASAP will also
> provide feedback to help us with work for other platforms or even for
> a follow-on rewrite of the Linux sandbox.

This would be a bad idea.  There's quite a bit of additional work that
would need to go into it to make it non-technical people ready, with the
big ones being:

 * The UI is a ugly knockoff of the TorLauncher UI, and the code is
worse, and it sucks to maintain.
 * A non-trivial amount of development time would need to be spent
making 8.0 work properly.
 * There are a large number of unresolved issues including but not
limited to:

   1. Being able to type in more than English.
   2. Better integration with the Tor Browser interface, particularly
relating to updates and configuration.
   3. Supporting more than the transports provided by obfs4proxy.
   4. No work has been done regarding the bridge auto-discovery, because
that started going in when I basically gave up on the project, due to
not wanting to have to write UI code for the rest of my life.
   5. Probably other things, that I forgot about.

> 3. TorLauncher Problem: One significant obstacle to bringing Yawning's
> sandbox to users has been the TorLauncher problem. That is:
> TorLauncher is a Firefox extension that launches and controls Tor via
> the control port. ideally (and in Yawning's design) we don't want
> networked Firefox launching Tor or talking to its control port at all,
> because Firefox is a colossal mass of potentially unsafe,
> Internet-connected code. But TorLauncher is quite complex and I
> believe that building a production-ready replacement is a serious
> undertaking.
> 
> Possible solutions include:
>  A. Remove privileges from Firefox after the existing TorLauncher runs.
>  B. Run TorLauncher in its own separate instance of Firefox which is
> not permitted to connect to the Internet, even via Tor. Then run
> Firefox connected to the SOCKS port separately.
>  C. Rewrite the TorLauncher in a safe language as a separate process
> using a UI based on Qt or similar.
>  D. Rewrite the back-end of TorLauncher in a safe language in a
> separate process, and keep the front-end (UI) in Firefox. The backend
> acts as an intermediary between Tor and Firefox to make sure only a
> small set of limited operations are allowed to occur.

C or D, with C being "better".  A is hard and OS specific.  B is a nasty
kludge that wants to be D when it grows up.

Regards,

-- 
Yawning Angel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20180730/69747a44/attachment.sig>