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

August 23, 2022

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).


Comments on this page:

By asciiphil at 2022-08-24 13:06:19:

Rather than through cron, my preference for this would be to integrate it into my configuration management system (Puppet, Chef, Ansible, etc.) Then if App Armor were enabled by something, it would be automatically detected and disabled again.

Have you considered booting with the kernel flag apparmor=0? That would prevent it from being enforced and also cause aa-enabled to return false. Seems better and cleaner than running aa-teardown randomly. Tested it just now just in case and works fine.

Also if that is not an option for whatever reason, the proper way to disable a specific profile is to symlink the /etc/apparmor.d/NAME profile into /etc/apparmor.d/disabled. So if for whatever reason the apparmor=0 method is not workable you could perhaps at least disable the known-problematic profiles that way so if things are reloaded by surprise then at least it won't break the ones you know about.

By cks at 2022-08-31 10:15:58:

The Ubuntu 22.04 kernels leak a significant amount of kernel memory if you have AppArmor turned off and auditing turned on, as we do. This is filed as Ubuntu bug #1987430. Until this is fixed, some people (including us) will find it impossible to run with AppArmor forcefully disabled in the kernel.

Written on 23 August 2022.
« Some notes on Grafana annotations sourced from Prometheus metrics
We now have some 1U servers with U.2 NVMe SSDs and they're okay »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Aug 23 22:49:57 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.