Should I disable AppArmor? July 7, 2009
Posted by jdstrand in security, ubuntu, ubuntu-server.Tags: canonical
trackback
Short answer: Of course not!
Longer answer:
Ubuntu has had AppArmor1 on by default for a while now, and with each new release more and more profiles are added. The Ubuntu community has worked hard to make the installed profiles work well, and by far and large, most people happily use their Ubuntu systems without noticing AppArmor is even there.
Of course, like with any software, there are bugs. I know these AppArmor profile bugs can be frustrating, but because AppArmor is a path-based system, diagnosing, fixing and even working around profile bugs is actually quite easy. AppArmor has the ability to disable specific profiles rather than simply turning it on or off, yet I’ve seen people in IRC and forums advise others to disable AppArmor completely. This is totally misguided and YOU SHOULD NEVER DISABLE APPARMOR ENTIRELY to work around a profiling problem. That is like trying to open your front door with dynamite– it will work, but it’ll leave a big hole and you’ll likely hurt yourself. Think about it, on my regular ol’ Jaunty laptop system, I have 4 profiles in place installed via Ubuntu packages (to see the profiles on your system, look in /etc/apparmor.d). Why would I want to disable all of AppArmor (and therefore all of those profiles) instead of dealing with just the one that is causing me problems? Obviously, the more software you install with AppArmor protection, the more you have to lose by disabling AppArmor completely.
So, when dealing with a profile bug, there are only a few things you need to know:
- AppArmor messages show up in /var/log/kern.log (by default)
- AppArmor profiles are located in /etc/apparmor.d
- The profile name is, by convention, <absolute path with ‘/’ replaced by ‘.’>. E.g ‘/etc/apparmor.d/sbin.dhclient3’ is the profile for ‘/sbin/dhclient3’.
- Profiles are simple text files
With this in mind, let’s say tcpdump is misbehaving. You can check /var/log/kern.log for entries like:
Jul 7 12:21:15 laptop kernel: [272480.175323] type=1503 audit(1246987275.634:324): operation="inode_create" requested_mask="a::" denied_mask="a::" fsuid=0 name="/opt/foo.out" pid=24113 profile="/usr/sbin/tcpdump"
That looks complicated, but it isn’t really, and it tells you everything you need to know to file a bug and fix the problem yourself. Specifically, “/usr/sbin/tcpdump” was denied “a” access to “/opt/foo.out”.
So now what?
If you are using the program with a default configuration or non-default but common configuration, then by all means, file a bug. If unsure, ask on IRC, on a mailing list or just file it anyway.
If you are a non-technical user or just need to put debugging this issue on hold, then you can disable this specific profile (there are others ways of doing this, but this method works best):
$ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.tcpdump
$ sudo ln -s /etc/apparmor.d/usr.sbin.tcpdump /etc/apparmor.d/disable/usr.sbin.tcpdump
What that does is remove the profile for tcpdump from the kernel, then disables the profile such that AppArmor won’t load it when it is started (eg, on reboot). Now you can use the application without AppArmor protection, but leaving all those other applications with profiles protected.
If you are technically minded, dive into /etc/apparmor.d/usr.sbin.tcpdump and adjust the profile, then reload it:
$ sudo <your favorite editor> /etc/apparmor.d/usr.sbin.tcpdump
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.tcpdump
This will likely be an iterative process, but you can base your new or updated rules on what is already the profile– it is pretty straightforward. After a couple of times, it will be second nature and you might want to start contributing to developing new profiles. Once the profile is working for you, please add your proposed fix to the bug report you filed earlier.
The DebuggingApparmor page has information on how to triage, fix and work-around AppArmor profile bugs. To learn more about AppArmor and the most frequently used access rules, install the apparmor-docs package, and read /usr/share/doc/apparmor-docs/techdoc.pdf.gz.
1. For those of you who don’t know, AppArmor is a path-based (as opposed to SELinux, which is inode-based) mandatory access control (MAC) system that limits access a process has to a predefined set of files and operations. These access controls are known as ‘profiles’ in AppArmor parlance.
Blog: jdstrand 
Add a GUI and you’ll get higher level o running AppArmors.
Without GUI – people will complain, other will tell them to disable and both will be happy.
Add a GUI. PolicyKit-based, as a tray icon program.
Sure, and this is planned (perhaps even for Karmic). That said, the few times I’ve seen the bad advice, it is normally related to server software.
Can’t I just delete the offending profile in /etc/apparmor.d/ and reboot?
Yes, but this isn’t recommended because you’ll have a hard time getting the profile back if you ever want it.
“That is like trying to open your front door with dynamite– it will work, but it’ll leave a big hole and you’ll likely hurt yourself.”
Uh huh. That’s just plain misleading. While AppArmor does add to the security of a system, you’re NOT *likely* to hurt yourself without it. Under certain conditions if you do all sorts of other things wrong, you *might* (and that’s a very strong might) create an issue. But it is in no way *likely*.
But I love the fear mongering, it makes Linux look like it’s really an insecure operating system.
You misunderstood the point. There are potentially many AppArmor profiles providing confinement on an Ubuntu system. If one is causing problems, it is silly to disable all of AppArmor because of it. The other profiles are doing their job just fine.
Hi just thought id mention that howtoforge.com particularly the ubuntu server ones always suggest to disable app armour.
Thanks! I went through howtoforge and added comments for this. Of course, the moderators must approve them… ;)
Maybe this is an old issue, and things are fixed in 10.04 and the upcoming 10.10.
However, an upgrade to a machine wants to improve the machine. When I upgraded to 9.10, things started failing, and apparmor was the cause. It had prevented my bind installation from running.
Since I am the start of authority for my domains, having named down for even a few minutes can be problematic.
Far worse, I spent a lot of time feeling helpless, because my machine which had worked stably moments before was refusing to let me start one of my most basic services, despite the fact that I had just given named basically every permission it could ask for, and despite the fact that it had worked just fine before the upgrade.
And the logs didn’t mention apparmor, they just have these “audit” messages. Fortunately, I happed to see apparmor in the boot sequence, and wonder whether it was at fault.
So the question is how many other cascading failures could I expect? How about my spam filtering going to hell? It did.
What others could I expect? How about the fact that I came in this morning, and my machine had crashed. And when I restarted it, apparmor wouldn’t let named run again, despite the fact that I had moved usr.sbin.named into force-complain?
No. Apparmor is an interesting idea, but until its designers get a better clue about how to interface it into systems, so that it doesn’t break the principle of least astonishment, I’m not having it.
The point behind my post is that you shouldn’t disable all of AppArmor if you are only having problems with a particular service. In your case, that would be bind’s profile, and you appropriately tried to disable only its profile. If AppArmor is not behaving as expected (eg ‘force-complain’ is not working), please file a bug at https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug. This will help us improve AppArmor in Ubuntu for others.
As for the failure after upgrade, the AppArmor profile should work fine with default and common configurations. If it does not, please file a bug (see above). If you made customizations to the profile, the upgrade process will prompt you on the conffile change, after which you will have to merge in your changes manually (either by accepting the maintainer’s version and putting your changes in or keeping the old version and adding in the maintainer’s changes). When upgrading software on a dpkg-based system, this is the expected behavior for conffile changes in /etc. AppArmor upstream recognizes that this process, while familiar to Debian administrators, is not ideal and are considering different ways to improve configuration management.
Lastly, and this is not at all AppArmor specific, I always recommend upgrade testing of critical services (or non-critical when feasible) on non-production machines to catch upgrade problems before they affect users. This can of course be done on bare-metal or in virtualization.
The other day I became aware of AppArmor in my Ubuntu server (still new at linux) and I decided to learn it.
It took me a day and now I’m creating my own profiles from scratch. Actually the tools can do it for me and I usually just clean up the paths by hand.
If there is any doubt, set a profile to complain/learning mode (meaning it will log but not restrict). Later on you can turn those log entries into an updated profile and return to enforce mode.
AppArmor seems like an excellent concept, but these profiles will take some tuning. I traced down a cups-pdf issue to its profile (it was unwilling to accept a change from defaults), but stupidly applied a “aa-complain /etc/apparmor.d/*” instead of “aa-complain /etc/usr.sbin.cupsd” or, even better, tuning the profile. I’ve now spent the last two hours trying to determine what the default mode of each of the other profiles I disabled was originally (10.10 MM). Any pointers would be appreciated. (I assume aa-complain went in and blew away the current mode text in each profile.)
OK, rather than having a .deb party I looked at another Ubuntu 10.10 installation. From the diff I saw setting aa-complain inserts “flags=(complain)” into each apparmor.d active profile. The clean Ubuntu install had *all* of them without the flag: gdm-guest-session, dhclient3, evince, firefox, cupsd, mysqld, ntpd, and tcpdump. All were enforcing. I moved all but cups back to enforcing.
Of the profiles you mentioned, firefox is also not enabled in the default install but ‘disabled’ rather than in complain mode. In Maverick, you can disable it again by doing:
$ sudo touch /etc/apparmor.d/disable/path.to.bin$ sudo apparmor_parser -R /etc/apparmor.d/path.to.bin
Natty has an ‘aa-disable’ command that will do the same. Of course, having the profile enabled for firefox will help protect against arbitrary code execution and access to very sensitive files. You may want to read more about the firefox profile and fine-tuning it. The cups profile provides good protection against exploits in cups and the libraries it depends on. Rather than disabling the cups profile I highly encourage you to read https://wiki.ubuntu.com/DebuggingApparmor and adjust the profile yourself for your environment. If you believe the changes would be worthwhile for all Ubuntu users, please file a bug. Thanks for your feedback! :)
Sorry for the issue you had. Most of the profile should work out of the box with no tuning for default and common configurations. If that is not the case, please file a bug at https://launchpad.net/ubuntu/+filebug.
Jamie, thanks for the info and advice. I had not noticed the symlinks in the disable folder. I’m keeping FF enabled and enforced. I also looked at launchpad per your note, and found over a dozen cups-pdf/apparmor interaction bugs listed. My exact issue was #147551, and is not considered a bug. I would think this points to a more general issue–users don’t know about AA when making standard config changes, and get silent failures. I’ve now installed apparmor-notify, which looks like a great way to avoid a surprise silent failure in the future. It seems like something like this needed to go in the same instant dists started setting enforce.