AppArmor profile packaging

Registered by Jamie Strandboge

For maintainers, AppArmor profiles are packaged either in the application that the profile applies to (eg, mysql or firefox) or in the apparmor-profiles package for profiles that are not officially supported yet (eg, they are in development). This presents maintenance difficulties and a barrier for people to include these profiles in their packages. This should be made easier.

For administrators, because AppArmor profiles are conffiles, modifying them causes pain on upgrades. This should be made easier.

Sharing profiles (eg, browser profiles for firefox and chromium) should be easier through careful use of abstractions. In the specific case of browser plugins, debconf may be able to be used to aid in configuration.

Blueprint information

Kees Cook
Jamie Strandboge
Needs approval
Jamie Strandboge
Series goal:
Accepted for maverick
Milestone target:
milestone icon ubuntu-10.10
Started by
Jamie Strandboge
Completed by
Jamie Strandboge

Related branches



Feedback jjohansen: kernel learning interface that doesn't spam logs to ease crowdsourcing, might not make feature freeze

Work items:
[jdstrand] investigate/implement dh_apparmor: DONE
[jdstrand] add 'local' file include to packaging and profiles for all packaging that ship an enforcing profile: DONE
[jdstrand] abstract out common accesses for browsers so firefox, chromium, et al profiles can be simplified: DONE
[jdstrand] create debconf configuration for browser plugins: POSTPONED
[jdstrand] write tool for managing browser plugins/apparmor snippets (usable by debconf): DONE
[jdstrand] update firefox profile to use the new abstraction and browser plugin configuration: DONE
[kees] discuss/implement how to do per-service AA profile loading via upstart with Keybuk: POSTPONED
[sbeattie] single tarball build tree: POSTPONED
[sbeattie] check in with RPM-based distros for buildability: DONE
[kees] clean up /etc files: POSTPONED
[jdstrand] write aa-disable: POSTPONED
[jjohansen] parser should be able to show all included abstractions: DONE
[jjohansen] kernel learning interface that doesn't spam logs to ease crowdsourcing: POSTPONED
[jjohansen] kernel flag to turn on learning mode from boot: DONE

Gobby notes:
Improve AppArmor profile packaging. Why?
 * minimizing the Ubuntu delta (important for merges)
 * why are maintaining these anyway, why not make it easier for us to not have to fiddle with others debian/ directories, etc
 * bugs easier to report/find-- always against 'apparmor'
 * core-dev should be able to commit to this bzr branch, so they can maintain their profiles anyway (especially for Depends and Recommends)
 * easier to integrate into a package. eg, ubuntuone client-- failed cause ubuntuone guys didn't know how to integrate it. We say-- here is a profile, please add a Depends on apparmor-profile-ubuntuone-client
 * easy to see in packaging what apparmor profiles are installed
 * potentially easier for SRU-- we can do a profile update on a large package like firefox without a lot of archive churn or coordination with the mozilla team

AppArmor packaging:
 1. move all of the profiles out of the packages
 2. packages can either Depends (eg bind9, mysql), recommends (eg firefox) or suggests (eg chromium) on apparmor-profile-<pkgname>. Eg apparmor-profile-firefox

  * Problems
   * merging just apparmor profiles on a per-package basis causes churn
     * adding dh_apparmor with enough logic can fix up packaging insanity
   * bugs
     * bugs _should_ be against the real package, not apparmor
   * maintainers are unsure about how to change/improve profiles
     * maintainers should be handling the profiles and packaging
     * security people can always be seen as a resource for questions
   * can't touch packages in main sometimes because the bzr trees don't get commit
     * this is a bug in the package control file -- if it's in the archive, coredev-ish
       people should be able to upload to the bzr tree.
  * Crowd sourcing of profiles can help with profile development

 3. have each of these ship the conffile for the base profile: eg /etc/apparmor.d/usr.bin.firefox
 4. create a .d directory: eg: /etc/apparmor.d/local
    - be careful about directory pollution
 5. have all the shipped profiles be like they are now, except also:
   #include <local/bind9>
 6. ship local/<pkg>.local as a config file -- ie, cp from /usr/share/apparmor/... on upgrades/install if doesn't exist

Sometimes more complicated interactions need to happen. Eg:
 * dhclient (the apparmor profile package can just drop a file in /etc/apparmor/init/network-interface-security/)
 * upstartification (just add a 3 line snippet to upstart script)

[action] kees: to get ideas from Keybuk about how to do per-service AA profile loading via upstart

Browser AppArmor packaging: [kees]
1. do as above
2. ideally have the userspace tools support an include directory. Eg:
3. have firefox include /etc/apparmor.d/abstractions/browsers.d
4. have debconf combobox like so:
[ ] java
[ ] Adobe Acrobat Reader
[ ] Flash
[ ] bittorent
[*] media players
[ ] firegpg
[ ] mozplugger
[ ] text editors
[ ] email clients
[*] PDF readers
5. if using an include directory, can drop snippets into the browsers.d directory. Otherwise, manage ubuntu/browsers

Alternate to 2 and 3: have firefox have both:
#include <local/firefox>
#include <ubuntu/browsers>

then have an upstream tool (usable by debconf) to manage ubuntu/browsers

• Firefox and Chromium (and seamonkey and epiphany) can all share the debconf configuration in step 4.
• makes it easy to enable/disable certain plugins and add-ons
• makes upgrades easier since users don't have to fiddle with conffiles

upstream packaging [kees, sbeattie]
 * single tarball/build tree
 * check in with RPM-based distros for buildability
 * move out rc.apparmor.funtions et al to somewhere more appropriate

/etc files [kees]
 * data types
  * operational configurations (repo, severity, subdomain.conf, logprof)
    * traditionally /etc/apparmor
  * profiles and abstractions (traditionally /etc/apparmor.d/)
  * cache (needs to be in /, perhaps under /lib instead of /etc)
  * init-support
     * functions
     * early-init profile lists (should be under /lib? probably not, since people need to modify it, so /etc/apparmor)
  * complain/disable via filesystem (perhaps move into /etc/apparmor)

* aa-disable [jdstrand]
* parser needs to grow back the ability to show all included abstractions, etc [jj]


Work Items