Shared memory for zygote mind meld

As I mentioned in #6937 (moved), I think we could really use a shared memory mutex as some kind meeting point for various Tor specific applications. This likely would be created by Tor or by a zygote that launches things like Tor and the Tor Browser. In theory, we could then have the launcher application and ensure we don't launch extra copies of Tor, we could ensure that we know how we may connect as well as how to authenticate; lots of stuff becomes possible with a little IPC love.

I have a sketch of the zygote/launcher process but I need to take it from my notepad to text, so I'm merely capturing this part of the process in this ticket. More tickets to come.

added component::applications/tor browser owner::tbb-team parent::19750 priority::medium severity::normal status::new tbb-sandboxing tbb-security type::enhancement labels

Sounds plausible to me. The first catch that comes to mind is that when Tor dies it needs to take down the shared memory hunk too -- and if it dies poorly, it might not be able to.

Replying to arma:

Sounds plausible to me. The first catch that comes to mind is that when Tor dies it needs to take down the shared memory hunk too -- and if it dies poorly, it might not be able to.

I was considering this last night and I thought of a possible solution to this problem.

We can ensure that the shared memory hunk has a pointer to a name of another shared memory hunk. If Tor goes down without taking down the shared global memory mutex, and an application cannot connect, the application with this zygote support can check the contents of the shared memory for an item that tells them where to create a new shared memory mutex. The zygote may then create a new tor instance, which will look at the previous instance, grab the old mutex name, increment to the next one or use the one left by the first Tor and start a fresh Tor. In this way, we can be sure that Tor will always have left a linked list behind that leads to a possible new Tor.

In essence tor-shim-000 will have a few points of application contact (ControlSocket, SocksSocket, SocksPort, TransPort, etc) and then other information that might be useful (pid of Tor, time of launch, pointer to next shared memory address in case this Tor dies badly, etc) to the zygote, to other applications and so on.

This should solve our auto-configuration problems and because we'll have security contexts, we can do SOCKS isolation on the SocksSocket by uid/gid, we can do security controls with uid/gid on the ControlSocket (and still freely share it), we can give out the pid without having to resort to some un-portable nightmare and so on.

The code name for this overall project is 'tzygotor' after Google's zygote.

It may be easier/simpler to take the approach of something like uuidd, which is spawned by libuuid on demand - and you just use a UNIX socket to connect to it (for Windows you'd do a named pipe).

Basically, the first tzygotor app launched would spawn tor and get a socket to do SOCKS things over, subsequent ones would just get the same socket without spawning it. It could even be that on the last tzygotor app exiting, the tor daemon is shut down.

Trac:
Username: stewart

Basically.. I've found that shared memory hard; sockets good. Especially cross-platform and in the event of failure.

Trac:
Username: stewart

For reference, a "zygote" is apparently a reference to part of the Chrome architecture.

I made an overview about the current limitations of communication between Tor, various bundles and applications. It's a list with feature requests and open trac tickets.

https://trac.torproject.org/projects/tor/wiki/doc/TB (yes, not best title)

Trac:
Cc: mikeperry, nickm, arma to mikeperry, nickm, arma, adrelanos@riseup.net

Stewart - I agree entirely. I think that is a fine idea overall. I'm still going to mess around with shared memory stuff but it won't be required for anything. I want to add ways of getting this stuff done and less and less asking of the user is best, I think.

Trac:
Cc: mikeperry, nickm, arma, adrelanos@riseup.net to mikeperry, nickm, arma, adrelanos@riseup.net, intrigeri@boum.org

Trac:
Keywords: N/A deleted, needs-triage added

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Trac:
Reviewer: N/A to N/A
Cc: mikeperry, nickm, arma, adrelanos@riseup.net, intrigeri@boum.org to mikeperry, nickm, arma, adrelanos@riseup.net, intrigeri@boum.org, sysrqb
Keywords: needs-triage deleted, tbb-security added
Sponsor: N/A to N/A
Owner: erinn to tbb-team
Component: Applications/Tor bundles/installation to Applications/Tor Browser

Trac:
Keywords: N/A deleted, tbb-sandboxing added

Trac:
Parent: N/A to #19750 (moved)

mentioned in issue #8038 (moved)

mentioned in issue #8936 (closed)

moved to tpo/applications/tor-browser#6948 (closed)