Ubuntu
click-apparmor package

[FFe] need method to reload policy on first boot after system-image upgrade

Bug #1229449 reported by Jamie Strandboge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
click-apparmor (Ubuntu)
Fix Released
High
Jamie Strandboge
Saucy
Fix Released
High
Jamie Strandboge

Bug Description

This bug addresses a deficiency in lxc-android-config (see bug #1215092) by adding an upstart job for click-apparmor. Not only does it handle that bug, it allows us in the future to clean up policy load during boot.

Justification:
Currently updates to system packages for RO images are run on the server with postinst, triggers, etc running there such that when an image based update is delivered, all of this already done. This works fine for most software, but it is not enough for click package apparmor profiles after the system has apparmor policy updates. Consider this scenario:
 1. user uses RO Ubuntu image on a device
 2. user installs 15 click packages
 3. bug is found in apparmor policy for the ubuntu-sdk apparmor template
 4. apparmor-easyprof-ubuntu is updated to correct the template
 5. image based upgrades picks this up and includes the new apparmor-easyprof-ubuntu in its update
 6. the update is delivered to users

At this point, newly installed click packages will get the apparmor policy fixes, but not the original 15. It is a requirement for application confinement that we are able to update policy for already installed click packages. Currently, policy updates may happen via apparmor, apparmor-easyprof-ubuntu and/or click-apparmor.

By shipping a click-apparmor upstart job, we can detect policy changes in these packages and act accordingly. Note, the click system hooks job is not enough, because that correctly uses 'aa-clickhook' without arguments. We must use 'aa-clickhook -f', but only when system policy has changed ('aa-clickhook -f' is more expensive than aa-clickhook on its own, adding a second or more to boot, so we should only use it when we have to).

See original description
Jamie Strandboge (jdstrand)
Changed in click-apparmor (Ubuntu Saucy):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → High
status: New → In Progress
tags: added: application-confinement
Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Revision history for this message
Adam Conrad (adconrad) wrote :

18:53 < infinity> jdstrand: Well, FFe granted for the feature, reservations registered about the vomitous implementation. :P

summary: - need method to reload policy on first boot after system-image upgrade
+ [FFe] need method to reload policy on first boot after system-image
+ upgrade
Revision history for this message
Adam Conrad (adconrad) wrote :

18:55 < infinity> jdstrand: Wait, if this is only on system image updates, where isn't there some system image post-update.d that things can drop snippets into?
18:55 < infinity> jdstrand: Seems this might be a general problem looking for a general solution.
18:55 < infinity> jdstrand: (Much like Android rebuilds its bytecompile cache after major upgrades)
18:56 < infinity> jdstrand: Maybe this needs a talk with other interested parties like stgraber to sort out a general "we just updated" hook system.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Please see bug #1215092 for the system image updates bit. I have left the click-apparmor task open there so I can hook into it when it becomes available and remove the dpkg bit. I will be revisiting apparmor policy load in general for 14.04, and will probably still use a click-apparmor upstart job, so the job is still relevant.

description: updated
Ubuntu Foundations Team Bug Bot (crichton)
tags: added: patch
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package click-apparmor - 0.1.10

---------------
click-apparmor (0.1.10) saucy; urgency=low

  * work around lack of first boot postinst-style code in lxc-android-config
    and ship a click-apparmor upstart job. This checks to see if apparmor or
    apparmor-easyprof-ubuntu's dpkg md5sums changed, and if so, runs
    'aa-clickhook -f'. This allows us to update policy for click packages on
    reboot after system-image updates. Note, the click system hooks job is
    not enough, because that correctly uses 'aa-clickhook' without arguments.
    'aa-clickhook -f' isn't normally needed so this job completes quickly
    in typical reboots ('aa-clickhook -f' still only updates the click policy
    that is affected). (LP: #1229449)
  * don't verify the policy before load. It will error on load which is
    equivalent to erroring out before load. This allows us to avoid parsing
    policy twice which can save significant time when regenerating lots of
    profiles, which is important during first boot after system upgrade
  * generated policy should be readable by everyone (the click security
    manifests are not private)
  * fix default path to apparmor_parser (thus avoiding a needless 'which')
  * debian/rules: cleanup .coverage and apparmor/__pycache__
 -- Jamie Strandboge <email address hidden> Mon, 23 Sep 2013 14:11:03 -0500

Changed in click-apparmor (Ubuntu Saucy):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.