touch-packages team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

So, if done right, this should not affect average users since on desktop
during the upgrade process, the upstart job will be called after the
unpack, and we already unconditionally invalidate the cache and
recompile on upgrades. This will update the files such that the cache
won't be cleared on the next invocation. Certainly, we need to make sure
we don't regress desktop/server in fixing a system-image issue, but I
don't think what Tyler is proposing will.

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

Title:
  System policy cache may become stale after a system image update

Status in “apparmor” package in Ubuntu:
  Triaged

Bug description:
  The system policy cache, in /etc/apparmor.d/cache, may become stale if
  a certain sequence of events occur at the correct time.

  1. Ubuntu developer modifies a profile and uploads a new apparmor package
  2. New apparmor package, with an updated profile, is used to build a new system image
  3. System policy cache on user's system gets regenerated
  4. User applies image update

  After 4), the timestamps on the files in the user's system policy
  cache will be newer than the timestamps on system profiles. The parser
  will not be able to detect that it ought to regenerate the policy
  cache so it will load the cached, but stale, binary policies.

  This can result in unexpected AppArmor denials if, for example, the
  apparmor package update loosens the confinement. On the flip side, it
  can result in a looser than expected confinement if the update further
  restricts confinement.

  The fix is to update the apparmor.conf upstart job to call
  clear_cache() if the apparmor package has been updated since the last
  time the job was invoked.

  Additionally, we may want to update the parser itself to manually set
  the mtime of a generate binary cache file to the earliest mtime seen
  while compiling the profile (this includes the mtime of the profile
  itself as well as any #include's).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1350673/+subscriptions