Comment 0 for bug 1326105

Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
  owner /run/user/[0-9]*/zmq/Registry-s rw,
  owner /run/user/[0-9]*/zmq/Registry-p r,
  owner /run/user/[0-9]*/zmq/c-*-r rw,

Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there a still a few issues:
 1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists? Defensive programming should be able to handle this case
 2. the /run/user/[0-9]*/zmq/c-*-r should also use standard defensive programming, but there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server.

For '1', standard defensive programming should be sufficient and someone should verify that the scopes API is handling when these files already exist (as sockets, regular files, etc, etc).

For '2', standard defensive programming should also be used, but that isn't enough. I suggested at the sprint that these endpoints cannot be made application specific by there name. I can (and will) update the apparmor policy to use this rule:
  owner /run/user/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,

but this doesn't solve the problem since a malicious app writer will just pick something matching that apparmor regular expression (AARE). AIUI, it is difficult/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq-local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.

Thanks!