touch-packages team mailing list archive

[Launchpad Bug Tracker <1326105@xxxxxxxxxxxxxxxxxx>]

*** This bug is a security vulnerability ***

You have been subscribed to a public security bug:

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 are 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?

 2. In addition to dealing with /run/user/[0-9]*/zmq/c-*-r possibly
already existing, 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 when the user upgrades (the fact that it is in /run
doesn't really help-- the malicious scope can save the file in its
scope-specific directory then copy it in to place to make sure it is
always there).

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 should be
made application specific by their name like with the other endpoints,
but was told this is problematic. 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 that match zmq/c-*-r.
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!

** Affects: unity-scopes-api (Ubuntu)
     Importance: Wishlist
     Assignee: Michi Henning (michihenning)
         Status: New


** Tags: application-confinement
-- 
AppArmor policy for scope zmq access is too lenient
https://bugs.launchpad.net/bugs/1326105
You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity-scopes-api in Ubuntu.