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

[Yawning Angel]

On Fri, 26 May 2017 15:39:16 -0500
Tom Ritter <tom at 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,

-- 
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/20170526/96797066/attachment.sig>