AppArmor is a Linux security module that helps protect your system by restricting what programs can do—without the complexity of SELinux.
Instead of adapting the complex SELinux system for its own distributions, the then owner of SUSE, Novell, bought the Immunix company, gave its security solution Subdomain the new name AppArmor, and placed it under the GNU General Public License (GPL). A few years later, AppArmor received the kernel developers’ accolade, so to speak, and was officially integrated into the kernel.
But after that, SUSE was silent on AppArmor. AppArmor remains in use, but no noticeable improvements have been made to either the rules or the admin tools in recent years. Instead, developers employed by Canonical have been responsible for the further development of AppArmor.
Like SELinux, AppArmor is a MAC security system. But in contrast to SELinux, App- Armor rules are based on absolute file names. For this reason, separate tagging of all files via EAs isn’t necessary; moreover, AppArmor also works for file systems that don’t support EAs.
Wildcards are allowed in the AppArmor rules. For this reason, AppArmor gets by with far fewer rules than SELinux for typical use cases.
However, there are also arguments against AppArmor:
- Security experts at Red Hat believe that absolute paths in rules are an inherent security risk. AppArmor’s protection can be bypassed by renaming files or directories—which of course only succeeds if an attacker already has sufficient rights to do so.
- The policy for AppArmor is not as comprehensive as that of SELinux. Fewer programs are protected by default. While it’s easier than with SELinux to create or change rules yourself, this kind of do-it-yourself security leaves a less than professional impression.
How AppArmor Works on Ubuntu
By default, AppArmor is integrated into the kernel on Ubuntu. The security system is started by systemd, takes into account the basic configuration from the /etc/apparmor directory, and loads all rule files from the /etc/apparmor.d directory.
When AppArmor is started, the securityfs file system is mounted in the /sys/kernel/ security directory. Its files provide information about active profiles, the number of rule violations that occurred, and so on.
The aa-status command shows the following:
- Total number of loaded profiles
- Number of profiles in enforce mode
- List of monitored services
- Associated process IDs/
The following code listing shows which services of an Ubuntu root server are monitored:
aa-status
apparmor module is loaded.
14 profiles are loaded.
14 profiles are in enforce mode.
/usr/bin/freshclam
/usr/bin/man
..
3 processes have profiles defined.
3 processes are in enforce mode.
/usr/bin/freshclam (919)
/usr/sbin/mysqld (816)
/usr/sbin/mysqld (24761) docker-default
In other words, there are only three active programs actually under the control of AppArmor: in addition to the MySQL server (which runs in two instances, once using Docker), AppArmor monitors the freshclam program, which periodically updates the virus database for the mail server.
There are various other AppArmor profiles, but as the programs in question aren’t running, these profiles remain ineffective.
Conversely, of course, there are various other server services running on the server that should be monitored (Apache, Dovecot, Postfix, SpamAssassin, an SSH server), but again, there are no official AppArmor rule profiles for them. So, compared to an SELinux system, the protection is more than sparse.
Understanding AppArmor Profiles
The effect of AppArmor depends on the monitoring rules. These rules are also referred to as profiles and are located in the files of the /etc/apparmor.d directory. For example, the usr.sbin.cupsd file contains the profiles for the CUPS printer system.
The officially maintained rule profiles are usually provided by the respective package. Thus, the user.sbin.cupsd rule profile is available only if you have installed CUPS. For this reason, /etc/apparmor.d is initially almost empty after an Ubuntu server installation and only fills up to the extent that you install server services.
Using AppArmor Modes: Enforce vs. Complain
You can also install the apparmor-profiles package from the universe package source. It contains numerous other profiles, but they are not officially supported and maintained. Most profiles only run in the complain mode.
In this mode, rule violations are logged but not penalized. You can use the aa-enforce and aa-complain commands from the apparmor-utils package to change the mode of a profile. To do so, you need to pass the full path of the program to be monitored to the two commands:
aa-enforce /usr/sbin/dnsmasq
Setting /usr/sbin/dnsmasq to enforce mode.
aa-complain /usr/sbin/dnsmasq
Setting /usr/sbin/dnsmasq to complain mode.
Alternatively, you can pass aa-enforce and aa-complain the file names of the profile files. This makes it easy to change the mode of multiple profiles at once:
cd /etc/apparmor.d
aa-enforce usr.lib.dovecot*
For server services, you must also restart the respective program after an AppArmor profile activation:
systemctl restart <name>
Inside an AppArmor Profile File
Rule files (profiles) have a plain text format. The following lines show part of the AppArmor rules for mysqld:
# File /etc/apparmor.d/usr.sbin.mysqld
#include <tunables/global>
/usr/sbin/mysqld {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/user-tmp>
#include <abstractions/mysql>
#include <abstractions/winbind>
capability dac_override,
capability sys_resource,
capability setgid,
capability setuid,
network tcp,
/etc/hosts.allow r,
...
/etc/mysql/** r,
/usr/lib/mysql/plugin/ r,
/usr/lib/mysql/plugin/*.so* mr,
/usr/sbin/mysqld mr,
/usr/share/mysql/** r,
/var/log/mysql.log rw,
/var/log/mysql.err rw,
...
/run/mysqld/mysqld.sock w,
/sys/devices/system/cpu/ r,
# Site-specific additions and overrides.
# See local/README for details.
#include <local/usr.sbin.mysqld>
}
In the rules files, some include files are read first before basic features of the program are defined. The other rules specify which files the program may use and how.
In AppArmor rules files, the wildcard character (*) is a placeholder for any number of characters. A double asterisk (**) has a similar meaning, but it includes the / character and thus includes files in all subdirectories. Access rights are expressed by letters or combinations of letters:
- r: Allows read access
- w: Allows write access
- a: Allows expanding a file (append)
- l: Applies the same rules to hard links as to the source file (link)
- k: Allows blocking (lock) a file
- m: Allows the mmap funcation (allow executable mapping)
- ix: The programs inherits the rules of the base program (inherent execute)
- px: The program has its own AppArmor profile (discrete profile execute)
- ux: Executes the program without AppArmor rules (unconstrained execute)
Tuning AppArmor with Variables
AppArmor provides a mechanism to change individual parameters of the rules in a simple way. These parameters are defined in the files of the /etc/apparmor.d/tunables directory. In the current implementation, however, there are only a few parameters, which you can determine as follows:
cd /etc/apparmor.d/tunables
cat $(find . -type f) | egrep '^@.*'
@{PROC}=/proc/
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ \
@{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mail/
@{securityfs}=@{sys}/kernel/security/
@{sys}=/sys/
@{apparmorfs}=@{securityfs}/apparmor/
@{HOME}=@{HOMEDIRS}/*/ /root/
@{HOMEDIRS}=/home/
...
How AppArmor Logs Security Events
Details about rule violations that occurred in complain or enforce mode are passed as kernel messages and are recorded by default in the /var/log/kern.log and /var/log/syslog files. You can recognize AppArmor messages by the audit keyword.
Some audit messages are simply an indicator that AppArmor rules are incomplete. Misbehavior in the program is of course also possible, but rather unlikely. Only an expert in the respective program can judge this with certainty. In this respect, an appropriate response to rule violations is difficult.
If you suspect that the affected program is working properly, you should switch the profile to the complain mode and report the audit message in the Ubuntu bug system (https://bugs.launchpad.net).
You can find more information on AppArmor at the following websites:
Editor’s note: This post has been adapted from a section of the book Hacking and Security: The Comprehensive Guide to Penetration Testing and Cybersecurity by Michael Kofler, Klaus Gebeshuber, Peter Kloep, Frank Neugebauer, André Zingsheim, Thomas Hackner, Markus Widl, Roland Aigner, Stefan Kania, Tobias Scheible, and Matthias Wübbeling. These authors are a team of security specialists who have decades of experience working as penetration testers, administrators, and developers. Their unique expertise has taught them how hackers operate and they use this insight to teach others how to effectively defend systems against attacks.
This post was originally published in 4/2025.
Comments