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

[Yawning Angel]

On Fri, 26 May 2017 17:45:03 -0700
"Arthur D. Edelstein" <arthuredelstein at 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,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170527/e2f28425/attachment-0001.sig>