[tbb-dev] Tor Browser TorLauncher Proposal

[Yawning Angel]

Hello,

This will be me beating one of my favorite dead horses about how
a TorLauncher extension shouldn't exist at all.  Feel free to ignore
it, because it doesn't directly pertain to all the API mapping things
in the proposal, but if you're going to do a mountain of work, maybe
think about fixing the design.

On Wed, 10 Jan 2018 15:10:21 +0000
Matthew Finkel <matthew.finkel at gmail.com> wrote:
> From the mobile/Android perspective, TorLauncher is a strange
> requirement at this moment. On Android, Orbot controls and configures
> tor, and external Apps cannot configure tor which is the purpose of
> TorLauncher. In the future, we may prefer another design and
> integration, providing a better user experience.

The Android model is closer to being correct than anything involving
TorLaucher or Firefox spawning children.  Specifically, from the
proposal:

>  Is there a way Tor Browser can further restrict access to a XPCOM
>  service? Firefox's sandboxing makes difficult unprivileged access to
>  internal services, but this risk remains when Tor Browser runs as a
>  single process.

This risk remains until:

 * The Firefox process is completely isolated from the tor process.

 * The Firefox process does not have external network access or
   unfettered file system access.

 * The Firefox process does not have free reign over absolutely
   everything the tor process does via the control port.

    Eg: `SETCONF ClientTransportPlugin` should terrify people.

>  As mentioned earlier, sandboxing the controller and process manager
>  into a sandboxed-child process would provide additional assurance the
>  tor process would not reveal private information if a vulnerability
>  is found in the Browser.

I don't think this helps much.  It protects Firefox from tor, when they
should be isolated and protected from each other.  Just from history,
the least trusted component in the pile of things that make up Tor
Browser, should be the browser.

>  What are the implications of the browser having access to the full
>  circuit information, including the User's guard?

Probably less bad than the implications of the browser having full
control over the Tor process via arbitrary control port commands.  As
it stands now, by virtue of Tor Launcher needing to exist and function,
Firefox has to be able to issue a lot more control port commands than
it should be.

Though even with the better model, there's still a laundry list of
things the Browser needs to be able to do to work such as setting the
user's bridge that can be be abused by malicious entities.

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/20180110/2e1b04c9/attachment.sig>