[tbb-dev] So, about the Linux sandbox in the long term?

[Tom Ritter]

On 26 May 2017 at 13:52, Arthur D. Edelstein <arthuredelstein at gmail.com> wrote:
> Hi Yawning,
>
> Thanks for bringing this up and thanks for your work on the sandbox.
> In my opinion, getting Tor Browser sandboxed should remain a high
> priority.
>
>> A few months ago I sent a detailed list of what remains to be done, and
>> a time estimate assuming someone was working full time.  However, to
>> be frank, I am increasingly uncertain as to if doing the improvements
>> (beyond the security/hardening ones) makes any sense because:
>>
>>  * It is my belief that the current Tor Browser architecture is
>>    diametrically opposed to what is required for proper
>>    containerization.
>
> Can you explain this a little further? Why are these diametrically opposed?

So I'm not sure about Linux, but on Windows I would agree with this.

Right now the current procedure, and plan, is:

firefox.exe starts
a hook starts running code in tor-launcher
(in the future, tor-launcher might do some auto-probing or auto-bridge download)
tor-launcher starts tor
firefox.exe talks to tor.exe


But what we'd like to get to is a place where firefox.exe (and its
content processes) can't talk to the network, they can only talk to
tor.exe (using a Windows Named Pipe on Windows, and Unix Domain
Sockets on Linux/Mac).

That's just half of the sandbox story though. You also have to
restrict firefox.exe (both content and parent processes) from doing
anything that will cause network requests to be created. Including:
- Spawning processes to talk to the network
- Loading libraries from remote hosts
- Injecting code into other processes
- Writing arbitrarily to the filesystem (things like the equivalent of
writing to .bashrc)
- Scheduling tasks
- etc etc

So if you do both of those things (restricting the browser from
talking to the network, and sandboxing it so even with arbitrary code
execution you still can't figure out a way to talk to the network) -
you can get strong defense in depth.


But wait a minute. If firefox.exe can't launch a process that can talk
to the network... how's it supposed to launch tor.exe? And how's it
supposed to talk to tor.exe over the control port?

Maybe, maybe.... you can set up the sandbox so firefox.exe spawns
tor.exe, creates a control port connection, and then sandboxes itself
so it can no longer spawn processes or talk to network sockets. I'm
not sure.

But in general, this is the problem I'm seeing for Windows. It might
be a similar problem to Yawning's.

-tom