touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

** Project changed: unity-scopes-api => unity-scopes-api (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-api in
Ubuntu.
https://bugs.launchpad.net/bugs/1326105

Title:
  AppArmor policy for scope zmq access is too lenient

Status in “unity-scopes-api” package in Ubuntu:
  New

Bug description:
  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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1326105/+subscriptions