Hi everyone,<br>
<br>
I just want to confirm that I&#39;m analyzing things correctly with regards<br>
to security in the IPython (and zmq) infrastructure. I&#39;ve read<br>
<a href="http://ipython.org/ipython-doc/dev/parallel/parallel_security.html" target="_blank">http://ipython.org/ipython-doc/dev/parallel/parallel_security.html</a><br>
(which notes that is not thorough and pyzmq needs a security audit) and<br>
<a href="http://ipython.org/ipython-doc/dev/parallel/parallel_intro.html#security" target="_blank">http://ipython.org/ipython-doc/dev/parallel/parallel_intro.html#security</a>.<br>
My aim is to have a client on one computer and a hub and engine on<br>
another computer, with the messages flowing between them as securely as<br>
if I had the client ssh into the hub/engine computer, run python, and<br>
captured the stdout. In particular, I want to prevent other users on<br>
either the client or the hub/engine machine from seeing messages or<br>
inserting their own messages, at least to the level of protection that<br>
ssh or filesystem permission controls provide (I trust those). And I&#39;m<br>
remembering the old adage that if I&#39;m hand-implementing the security,<br>
I&#39;m doing it wrong.<br>
<br>
As I understand it now (am I assessing the situation correctly?), I can<br>
use ssh to tunnel the messages from the client computer to the engine<br>
computer. From there, the messages are transmitted over tcp via the<br>
loopback to the hub, and then again over tcp via the loopback to the<br>
engine. Well, in reality, the message may not actually go through the<br>
entire tcp stack since the loopback interface can be optimized on the OS<br>
level. IPython has implemented some controls for rejecting messages<br>
that are not signed with specific authentication credentials, so if I<br>
securely transmit and store the credentials (using ssh and filesystem<br>
permissions), things *should* be okay as long as the loopback interface<br>
is not compromised. However, the loopback interface still allows<br>
connections from anyone on the local computer to any port, and the hub<br>
and engines still take up ports on the server. So if an untrusted user<br>
exploited a bug in the signing mechanism, or wanted to do some sort of<br>
DNS attack, that would be possible.<br>
<br>
Is it possible to instead have the messages go over unix domain sockets<br>
(via the zmq ipc transport), which could then be protected using<br>
filesystem permissions? In that scenario, the client could have an ssh<br>
tunnel to the hub/engine machine, then connect via IPC to the hub. The<br>
unix domain socket address would be protected by necessary filesystem<br>
controls so that untrusted users on the hub/engine machine couldn&#39;t even<br>
connect to the hub. In fact, if the client, hub, and engine were all<br>
running on the same computer as the same user, the socket could be set<br>
to have no permissions for other users, providing a secure message<br>
pathway. Am I thinking of things correctly? Using these sockets seems<br>
to take one potential worry out (any user being able to connect to the<br>
hub or engine).<br></blockquote><div><br></div><div><br></div><div>I just tried IPC on my latptop, and it definitely does work, though the config is a bit weird, due to some assumptions that TCP is what people actually use:</div>

<div><br></div><div>will result in a bunch of files called `$HOME/ipcluster/socket:12345`. This sets up IPC communication for the cluster.</div><div><br></div><div>The only thing I don&#39;t know about is forwarding UDS connections from the client to the Hub, but if you know how to do that, you might be set (some code would need to change in the ssh forwarding utils, but that shouldn&#39;t be much).</div>