On 26 May 2017 at 13:52, Arthur D. Edelstein arthuredelstein@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