[tbb-dev] So, about the Linux sandbox in the long term?
yawning at schwanenlied.me
Fri May 26 21:26:16 UTC 2017
On Fri, 26 May 2017 15:39:16 -0500
Tom Ritter <tom at ritter.vg> wrote:
> 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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the tbb-dev