Agenda
======

Goal: defining a strategy for AppArmor in Debian.

* intro: what's AppArmor, what's its status in Debian currently
* kernel
* userspace
* policy
* packaging
* enabling by default in Jessie+1?

Intro
=====

* AppArmor is MAC (Mandatory Access Control) mechanism in kernel, can block
  operations regardless of e.g. file permissions
* Policy may be included in package it applies to, or externally
* Some packages have policy files from upstream that haven't been tested in
  Debian
* Administrator may add local overrides to /etc/apparmor.d/local/ without
  editing packaged policy
* popcon for apparmor: ~300 votes (tomoyo-tools: 6 votes, selinux-tools: 592 votes)


Kernel
======

Lots of features in Ubuntu that haven't been upstreamed yet; more are coming.
Ubuntu is kinda used as a test bed: once the patches are solid enough, then
they can possible be upstreamed.

Mostly one person working on it, would really like to see it in the mainline
kernel, but time...

Debian tracks the mainline kernel. This triggers warnings at policy
parsing time, e.g. when profiles define network mediation rules.
Shall we hide these warnings, or remove the unsupported rules from the policy
we ship, or have the warning point to documentation, or what?

* Hiding the warnings is problematic, as then users may think that e.g.
  network mediation is active, while it's not.
* We can try to convince Canonical's management to prioritize upstreaming
  AppArmor kernel patches higher. They appearantly want to improve
  the Ubuntu/Debian collaboration too, which effectively can only happen
  if patches are upstreamed
* Short-term: improve the warnings to point to doc:
  - write doc [intrigeri]
  - patch the userspace tools [kees]
* We won't particularly insist to have more out-of-tree kernel patches
  on Jessie.


Userspace
=========

Here too, Ubuntu's packaging is basically a testbed for new upstream stuff.
Kees has been trying to track "pure" upstream instead.
Shall we go on this way, or start tracking Ubuntu's packaging?
Upstream tarballs may not be getting the attention they deserve, as most
distros don't really ship it as-is.



XXX: what userspace version in Jessie? 2.8.x or 2.9.x?
     https://bugs.debian.org/746764
	(waits for upstream release)

Policy
======

* Long-term, policies should be shipped in the individual packages
* there is apparmor-profiles-extra for policies not yet included in the
  correspondent package - the long term goal is to make that package useless
  or turn into a apparmor-profiles-hardened package

Packaging
=========
* apparmor packaging in Debian is behind Ubuntu, mostly because kernel features are lacking.
* better to follow upstream usertools instead of Ubuntu patch series for better testing.
* announce usertag to track apparmor bugs and inform maintainers that we're happy to help fix apparmor related bugs (eg work on profiles)

Jessie+1
========

* Needs kernel patches to go upstream so policies are completely applied
* Needs more users testing this stuff
* Needs to make it clear that we have a team that can help package
  maintainers with AppArmor -related problems, usertags, etc.
* autopkgtest could help: if a package has that and an AppArmor policy, then
  testing it also tests the policy (if the system that runs autopkgtest has
  AppArmor enabled)
* the apparmor package has support for enabling it by default as this is used
  in Ubuntu already, just this code is not used in Debian yet


Misc
----
* certain profiles are not applied because they are loaded too late -> bug filing
  (e.g. dhclient, ntpd); will be easier once the AppArmor/systemd interaction
  is clarified and improved. systemd v210+ knows how to load and apply a
  given profile to a service, which should help (e.g. for ntpd).
 - aa-status can list such processes

Pointers
========

* use: https://wiki.debian.org/AppArmor/HowTo
* help: https://wiki.debian.org/AppArmor/Contribute
* discuss: https://lists.alioth.debian.org/mailman/listinfo/pkg-aa-profiles-team