AppArmor profile packaging

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:
/etc/apparmor.d/abstractions/browsers.d
3. have firefox include /etc/apparmor.d/abstractions/browsers.d
4. have debconf combobox like so:
[ ] java
[ ] Adobe Acrobat Reader
[ ] Flash
[*] Openoffice.org
[ ] 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

Why?
• 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]