How does my AppArmor profile get into Debian?

I have spent the last days trying to understand the relationship between AppArmor, the AppArmor profiles and Debian’s AppArmor profiles. Let me try to briefly introduce you to this.

First of all, let me emphasize that one needs to distinguish between AppArmor, the kernel module, the AppArmor userspace tools and the AppArmor profiles, which define rules for application confinement. As stated on the project’s wiki:

The AppArmor project source is split between the kernel module, available in the Linux kernel and git development tree and the user space tools available in launchpad.

So, we can find the upstream AppArmor profile development taking place at Canonical’s launchpad.  The profiles which are developed there serve as a basis for some of those included in Debian. It is thus useful to try to contribute to this upstream when updating a profile for Debian.

The AppArmor userspace tools are shipped in the apparmor and apparmor-utils Debian packages, and are all built from the apparmor source package.

Since AppArmor 2.9 has been introduced, the rules of a profile which are not supported by the AppArmor parser  and running kernel are ignored. (The AppArmor 2.8.x parser would fail to load a profile that has e.g. mount or signal rules, unless the kernel had out-of-tree patches applied to support them.)
Thus, collaboration between different Linux distributions shipping AppArmor will become much simpler.

In the aforementioned Launchpad repository you can find the profiles that are currently in development. For Ubuntu, once tested and ready, they are removed from this repository and finally included into the corresponding package. For example, the profile for Evince, the GNOME PDF viewer, is available in the evince package.

In Debian however, there are only some packages which ship their own profiles. This concerns for example bind, clamav, cups, tor. But many profiles are not – yet – included with their package, and are instead delivered through the apparmor-profiles and apparmor-profiles-extra packages. These are maintained by the the Debian AppArmor packaging team. The team takes care of merging changes from the upstream profiles into Debian, and vice-versa.

Today, the relationship between Upstream and Debian looks like this:

Upstream/bzr

Debian source package

Debian binary package

Ubuntu source package

Ubuntu binary package

apparmor

apparmor

apparmor and apparmor-profiles

apparmor

apparmor

apparmor-profiles

apparmor-profiles-extra

apparmor-profiles-extra

apparmor-profiles

apparmor-profiles

apparmor-profiles-extra

apparmor-profiles-extra

evince

evince

tlsdate

tlsdate

tlsdate

tlsdate

tlsdate

In the future, this should change. It would indeed be desirable that Debian package maintainers include profiles with the packages they maintain and take care of updating them accordingly when the package itself is updated. It is much more logical to do it that way, as changes in a package like Pidgin or Evince can occur at a different point in time than when the apparmor-profiles-extra package is updated. Furthermore, it’s the package maintainer who is the most knowledgeable to actually test a program that is being confined by an AppArmor profile.

I started working on a documentation for Debian Package Maintainers which describes how to ship, test and debug an AppArmor profile with your package. This documentation will receive many updates during the next months.

 

rike

 

Leave a Reply

Your email address will not be published. Required fields are marked *