Workers bind to external network interface by default

[garrison]

When running julia -p 2, I was surprised to learn that the workers are told to bind to my external network interface.

$ ps x
 5144 pts/12   Sl+    0:01 ./julia -p 2
 5152 ?        Ssl    0:00 /home/garrison/julia/usr/bin/julia -Cnative -J/home/garrison/julia/usr/lib/julia/sys.ji --bind-to 192.168.1.101 --worker
 5153 ?        Ssl    0:01 /home/garrison/julia/usr/bin/julia -Cnative -J/home/garrison/julia/usr/lib/julia/sys.ji --bind-to 192.168.1.101 --worker

I would have hoped that a UNIX domain socket would be used if all the workers are on the local machine. (Failing that, binding to localhost would make a lot more sense, although this is still problematic from a security standpoint.)

[vtjnash]

binding to a local port would prevent heterogeneous networks consisting of both local and remote clients so it is typically undesirable to bind to localhost. (it is possible to add/remove workers at runtime, so it's not possible to known ahead of time if all workers will be local)

the kernel should fast-track the data as if it was declared using a unix domain socket, so there's no benefit there from performance.

i'm not sure i understand the security argument. are you assuming some malicious process will discover the remote port and try to become part of the pool? that would be bad, but to solve that it sounds like the master process should be emitting a private token to stdin immediately upon startup of the client that would act as the shared secret for any client wishing to join the processor pool.

[garrison]

Yes, my main concern here is security. I don't like the idea that julia is listening on an external network interface without me giving it an explicit instruction to do so.

i'm not sure i understand the security argument. are you assuming some malicious process will discover the remote port and try to become part of the pool? that would be bad, but to solve that it sounds like the master process should be emitting a private token to stdin immediately upon startup of the client that would act as the shared secret for any client wishing to join the processor pool.

My concern is that a malicious connection (which could originate, it seems, from another user on the same machine; from another person on the same network; or from somebody far away on the internet) could connect to the port a worker has binded to and gain control of it.

Perhaps the method you suggest would work as a line of defense. The piece of code implementing this deserves to be audited pretty thoroughly though, as a single bug could lead to a compromised process. Even then, most people who think even passingly about security will prefer not to have julia workers listening on external ports (EDIT: unless, of course, they are running workers on multiple machines, in a controlled environment). Appropriate firewalling could mitigate the problem, but should not be relied on.

As a tangent thought (ignoring the security concern for a moment, although that is my primary concern), I'm not sure why it binds to a specific network interface (192.168.0.101 on my system). If each worker process were to be available everywhere, I would expect it to bind to 0.0.0.0 instead.

[amitmurthy]

It is actually listening on all interfaces. The bind-to is the address it expects other processes from remote hosts to connect at. Except on the node running the master process, local workers always connect at 127.0.0.1 - this helps the specific use case of a laptop being put to sleep and getting a different IP on wakeup.

[amitmurthy]

closed by #16292