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.
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
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
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
periodically, perhaps from cron. You might think that disabling
AppArmor on the kernel command line is what you want, but the signs