touch-packages team mailing list archive

[Seth Arnold <1350673@xxxxxxxxxxxxxxxxxx>]

Clearing the cache is expensive; if this chain of events will only
affect 'developers', that's not ideal but tolerable. But if it'll affect
average users we should really try to avoid clearing the cache.

I haven't thought this through very far, but I wonder if we can do a
better job solving this if we store a hash of all the input used to
generate a binary cache file. We could use a Merkle tree if we wanted to
avoid recomputing hashes of repeatedly #included files. (That'd be an
optimization far easier to implement if the parser loads a directory of
policy itself...)

I'm thinking these time-based markers just aren't a good fit for us.

Thanks

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