From ArchWiki
Jump to: navigation, search

AppArmor is a Mandatory Access Control (MAC) system, implemented upon the Linux Security Modules (LSM).

AppArmor, like most other LSMs, supplements rather than replaces the default Discretionary Access Control (DAC). As such it's impossible to grant a process more privileges than it had in the first place.

Ubuntu, SUSE and a number of other distributions use it by default. RHEL (and its variants) use SELinux which requires good userspace integration to work properly. SELinux attaches labels to all files, processes and objects and is therefore very flexible. However configuring SELinux is considered to be very complicated and requires a supported filesystem. AppArmor on the other hand works using file paths and its configuration can be easily adapted.

AppArmor proactively protects the operating system and applications from external or internal threats and even zero-day attacks by enforcing a specific rule set on a per application basis. Security policies completely define what system resources individual applications can access, and with what privileges. Access is denied by default if no profile says otherwise. A few default policies are included with AppArmor and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.

Every breach of policy triggers a message in the system log, and AppArmor can be configured to notify users with real-time violation warnings popping up on the desktop.


AppArmor is available in linux (since 4.18.8.arch1-1), linux-zen (since 4.18.8.zen1-1) and linux-hardened (since 4.17.4.a-1).

To enable AppArmor as default security model on every boot, set the following kernel parameters:

apparmor=1 security=apparmor

Install apparmor for userspace tools and libraries to control AppArmor. To load all AppArmor profiles on startup, enable apparmor.service.

Custom kernel

When compiling the kernel, it is required to set at least the following options:


To use AppArmor as the default Linux security model and omitting the need of setting kernel parameters, also set the following options:



Display current status

To test if AppArmor has been correctly enabled:

$ aa-enabled

To display the current loaded status use apparmor_status:

# apparmor_status
apparmor module is loaded.
44 profiles are loaded.
44 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Parsing profiles

To load (enforce or complain), unload, reload, cache and stat profiles use apparmor_parser. The default action (-a) is to load a new profile in enforce mode, loading it in complain mode is possible using the -C switch, in order to overwrite an existing profile use the -r option and to remove a profile use -R. Each action may also apply to multiple profiles. Refer to apparmor_parser(8) man page for more information.

Disabling loading

Disable AppArmor by unloading all profiles for the current session:

# aa-teardown 

To prevent from loading AppArmor profiles at the next boot disable apparmor.service. To prevent the kernel from loading AppArmor, remove apparmor=1 security=apparmor from the kernel parameters.


Auditing and generating profiles

To create new profiles the Audit framework should be running. This is because Arch Linux adopted systemd and doesn't do kernel logging to file by default. AppArmor can grab kernel audit logs from the userspace auditd daemon, allowing you to build a profile.

New AppArmor profiles can be created by utilizing aa-genprof(8) and aa-logprof(8) tools available in apparmor package. Detailed guide about using those tools is available at AppArmor wiki - Profiling with tools.

Alternatively profiles may be also created manually, see guide available at AppArmor wiki - Profiling by hand.

Understanding profiles

Profiles are human readable text files residing under /etc/apparmor.d/ describing how binaries should be treated when executed. A basic profile looks similar to this:

#include <tunables/global>

profile test /usr/lib/test/test_binary {
    #include <abstractions/base>

    # Main libraries and plugins
    /usr/share/TEST/** r,
    /usr/lib/TEST/** rm,

    # Configuration files and logs
    @{HOME}/.config/ r,
    @{HOME}/.config/TEST/** rw,

Strings preceded by a @ symbol are variables defined by abstractions (/etc/apparmor.d/abstractions/), tunables (/etc/apparmor.d/tunables/) or by the profile itself. #include includes other profile-files directly. Paths followed by a set of characters are access permissions. Pattern matching is done using AppArmor's globbing syntax.

Most common use cases are covered by the following statements:

  • r — read: read data
  • w — write: create, delete, write to a file and extend it
  • m — memory map executable: memory map a file executable
  • x — execute: execute file; needs to be preceded by a qualifier

Remember that those permission do not allow binaries to exceed the permission dictated by the Discretionary Access Control (DAC).

This is merely a short overview, for a more detailed guide be sure to have a look at the apparmor.d(5) man page and documentation.

Tips and tricks

Get desktop notification on DENIED actions

The notification daemon displays desktop notifications whenever AppArmor denies a program access. To automatically start aa-notify daemon on login follow below steps:

Install and enable Audit framework. Allow your desktop user to read audit logs in /var/log/audit by adding it to audit user group:

# groupadd -r audit
# gpasswd -a <username> audit

Add audit group to auditd.conf:

log_group = audit
Tip: You may use other already existing system groups like wheel or adm.

Create desktop launcher with the below content:

[Desktop Entry]
Name=AppArmor Notify
Comment=Receive on screen notifications of AppArmor denials
Exec=/usr/bin/aa-notify -p -s 1 -w 60 -f /var/log/audit/audit.log

Reboot and check if aa-notify daemon is running:

$ ps aux | grep aa-notify
Note: Depending on your specific system configuration there could be A LOT of notifications displayed.

For more information, see aa-notify(8).

Speed-up AppArmor start by caching profiles

Since AppArmor has to translate the configured profiles into a binary format it may significantly increase the boot time. You can check current AppArmor startup time with:

$ systemd-analyze blame | grep apparmor

To enable caching AppArmor profiles, uncomment:

## Turn creating/updating of the cache on by default

To change default cache location add:

Note: Since 2.13.1 default cache location is /var/cache/apparmor/, previously it was /etc/apparmor.d/cache.d/.

Reboot and check AppArmor startup time again to see improvement:

$ systemd-analyze blame | grep apparmor


Failing to start Samba SMB/CIFS server

See Samba#Permission issues on AppArmor.

See also