On Fri, 26 May 2017 17:45:03 -0700 "Arthur D. Edelstein" arthuredelstein@gmail.com wrote:
Thanks for the clarifications, Tom and Yawning.
I'm curious what the long term plans for the sandbox are
It seems there are different threats due to browser exploits we are discussing here: (1) pwnage of the whole computer, (2) modifying the browser or tor binaries, (3) modifying the torrc or otherwise launching tor in a malicious way, and (4) one-time deanonymization via the ControlPort. So I wonder if it would make send to take a gradual approach in which defenses are deployed one by one, starting with the low-hanging fruit and working upwards. Something like:
Beyond, "this would be a massive duplication of effort", there's nothing preventing something like this.
Step 1: Containerize the whole bundle to defend against pwnage of the whole computer. Step 2: Create a external update mechanism and prevent firefox.exe from writing to its own directory or the tor directory. Step 3: Patch tor so that tor-launcher doesn't need to write to torrc at all to configure tor. Launch tor independently of the browser, but still configure tor using the tor-launcher extension UI, via a filtered control port. Prevent firefox from accessing tor directory or launching tor. Step 4: Write a new tor-controller UI in QT or similar that replaces functionality in tor-launcher and maybe the circuit display.
The existing Linux sandbox does all of this already. Re-doing something that already exists (twice), seems somewhat silly to me.
Am I right in thinking that there is a substantial security benefit to each step?
Sure.
And would it be feasible to deploy each step to users in standard Tor Browser without waiting for the next step to be ready?
Might be tricky for other reasons, but I guess? The big gotcha is that containerization is a privileged operation on sensible Linux systems.
Regards,