On Fri, 26 May 2017 15:39:16 -0500 Tom Ritter tom@ritter.vg wrote: [snip]
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.
Nailed it.
There's a few other things like filesystem visibility (firefox.exe should *NEVER* have visibility into tor's runtime state directory, but needs that to launch tor) related issues, but it's essentially the same problem.
I will note that there is nothing keeping anyone from writing a `tor-launcher` addon that does everything that `sandboxed-tor-browser` does (tor-launcher's functionality, updates, launching tor) that re-launches a restricted copy of firefox.exe as a child process, at least on Linux, with quite a bit of effort.
I am uncertain about other operating systems, and that sort of approach scares me, primarily because "pulling in a full web browser to do things a smaller self-contained executable can do" feels like a poor design choice and a nightmare to audit.
AFAIK this privilege inversion issue is also a problem on OSX. The main difference there (beyond "different platforms"/feature completeness) is that, instead of `sandboxed-tor-browser`, users get two shell scripts that they need to invoke manually.
The short version of what I view as a "correct" approach is "abandon tor-launcher, and go back to having an external launcher process like we did when vidallia was a thing, but actually maintain it this time", because having something like that independent/external to Firefox makes more sense architecturally.
Regards,