Wandering Thoughts archives

On Ubuntu, AppArmor is quite persistent and likes to reappear on you

We don't like AppArmor, in large part because it doesn't work in our environment; the net effect of allowing AppArmor to do anything is that periodically various things break mysteriously (for instance, Evince stops working because your $XAUTHORITY is on an NFS mounted filesystem). We do our best to not install AppArmor at all, and if it gets dragged in by package dependencies, we try to disable it with a heaping helping of systemd manipulation:

systemctl stop apparmor.service
systemctl disable apparmor.service
systemctl mask apparmor.service

If you boot an Ubuntu system this way, everything will look fine. The aa-status command will report that nothing is loaded or active, and nothing goes wrong because AppArmor is in the way. So you go on with life, leaving your systems up (as one does if possible), and then one day you run aa-status again (or try to use Evince) and discover, to your (our) surprise, that AppArmor is reporting things like:

apparmor module is loaded.
5 profiles are loaded.
5 profiles are in enforce mode.
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/cupsd (15098) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

What seems to be going on is that Ubuntu package updates for packages with AppArmor profiles activate those profiles whether or not AppArmor is supposed to be running. As packages get updated over time on your systems, a steadily increasing number of profiles will get silently turned on and then possibly shoot you in the foot.

The specific mechanism for some packages is that they have postinst scripts that check to see if AppArmor is enabled only with 'aa-enabled', which apparently only cares if AppArmor is enabled in the kernel, not if the AppArmor service has been masked, stopped, or whatever. When aa-enabled reports that yes, your Ubuntu kernel has AppArmor enabled because that's the normal condition, the package's postinst script enables its profile and suddenly you have potential problems.

It's possible that some AppArmor profiles get enabled through other mechanisms as well. Even if that's not the case in current Ubuntu LTS releases, I don't think you can count on it to stay that way in the future, and I'm certainly not expecting Canonical to fix aa-enable or their postinst usage of it. It seems pretty clear that Canonical has not exactly devoted much effort to insuring that their systems still work correctly for people who dare to deviate from the Ubuntu way by turning off AppArmor.

In Ubuntu versions that have it available, all I can suggest is running 'aa-teardown' periodically, perhaps from cron. You might think that disabling AppArmor on the kernel command line is what you want, but the signs suggest otherwise (also).