Comment 2 for bug 1347177

The zmq/*-r endpoints are for a client to receive replies in response to queries. Basically, when a client creates a query, it passes an invocation handle to the query that points at the zmq/*-r endpoint. The scope sends push messages to that endpoint to deliver the results.

It's OK for anything to connect to the reply endpoint and write to it. If the message arriving at that endpoint doesn't make sense (is malformed in some way, so it doesn't decode correctly, or similar), the message is discarded.

Each message has its internal structure. One of the things it contains is an object identifier (a UUID) that determines which query the reply is for (because a client may potentially have several queries in progress concurrently). When the client creates the query, it generates a new UUID for each query; that UUID is embedded in the invocation handle that is passed to the scope, and the UUID goes on the wire when the client pushes the results.

If a push arrives at the client's zmq/*-r endpoint with a UUID that doesn't correspond to the UUID of a currently outstanding query, the message is discarded.

So, the absolute worst that could happen is that a malicious process could try to push results to the reply endpoint of a client while the client has a query in progress, in an attempt to inject fake query results into the client. For that to work, the attacker would have to correctly guess the UUID for the query, and would have to do so while real scope is still busy executing the query. The UUIDs have 64 bits of entropy that comes from a Mersenne twister. I thought that this would make it sufficiently secure?

Query *creation* needs to be secured, and query creation in a scope happens via the zmq/*-q endpoint. Confined scopes must not be able to connect other scopes' query endpoint, but unconfined scopes should be allowed to, whether the target is confined or not.