Overview

AppArmor is a Mandatory Access Control (MAC) system built on the Linux Security Module (LSM) framework. It confines individual programs to the resources described in a per-application profile, so a bug — or a zero-day — in one application cannot be used to reach parts of the system that profile never granted. Unusually among the major LSMs, AppArmor policy is written against file paths and glob patterns rather than inode labels, which keeps a profile readable to an administrator who has never studied a policy language.

Enforcement happens in the kernel, so a confined process cannot switch it off or widen its own permissions: the restrictions are mandatory and are not bound to identity, group membership or file ownership, which means they also restrain programs running as root. AppArmor has been in the mainline Linux kernel since 2.6.36 and its userspace development has been supported by Canonical since 2009; it is the default major LSM on Ubuntu and on openSUSE/SUSE, and it ships with Debian, Alpine and other distributions. The kernel side plus the userspace tools in the apparmor/apparmor repository are licensed GPL-2.0, with libapparmor under the LGPL so that non-GPL binaries may still call change_hat(2) and change_profile(2).

Key Features

• Path-based profiles — rules name files, directories and globs (/etc/nginx/** r, /var/log/nginx/*.log w) with separate read, write, memory-map, link and lock permissions, plus execute modes (ix, ux, px, cx) that decide whether a spawned program inherits the profile, runs unconfined, or transitions to a profile of its own.
• Complain mode for safe rollout — aa-complain puts a profile into learning mode where denied operations are logged but allowed, so a new profile can be tuned on a production host without breaking it. aa-enforce, aa-audit, aa-disable and aa-teardown move profiles between modes from the command line; the aa-status summary reports how many profiles are loaded and how many are enforcing, complaining or unconfined.
• Profiles generated from real denials — aa-genprof and aa-logprof read the denial records the kernel emits, present them interactively and write the resulting rules back into the profile, which turns policy authoring into a guided workflow instead of guesswork.
• Mediation well beyond the filesystem — profiles also gate Linux capabilities, network sockets (including the upstream v8 socket rules), DBus messages, mount operations, ptrace, signals and other inter-process communication, so a profile describes everything a program may do, not just what it may open.
• Abstractions and tunables — shared include fragments such as abstractions/base and abstractions/nameservice avoid repeating common library, locale and DNS access rules in every profile. A normal desktop/server installation accumulates well over a hundred entries under /etc/apparmor.d from the distribution plus third-party packages (browsers, container tools, editors).
• Profile transitions, hats and stacking — change_profile and change_hat let a program drop into a narrower confinement context per request (used by mod_apparmor for Apache and pam_apparmor for PAM sessions), and AppArmor supports stacking policies on top of one another as well as being combined with other LSMs.
• Auditable denials — every denial is written as an apparmor="DENIED" record to the kernel log, syslog, journald or auditd, naming the profile, the attempted operation, the object and the process, which makes both troubleshooting and compliance reporting straightforward.
• Editor support and tooling — the userspace ships apparmor_parser, aa-unconfined (lists processes running without confinement), aa-notify, aa-decode, aa-features-abi and an apparmor.vim syntax file.

Why Use It

• Least privilege for long-running daemons — a web server, DNS resolver or database can be confined to exactly the files and sockets it needs, so a remote-code-execution flaw stops at the profile boundary rather than becoming full host compromise.
• Containment is mandatory, not discretionary — unlike file permissions, a profile cannot be relaxed by the process being confined, and it is enforced for root as well, which closes the classic privilege-escalation path from a compromised service to the whole machine.
• A shorter learning curve than label-based MAC — because policy is expressed in paths, a profile can be reviewed by anyone who understands the application’s file layout; the complain-mode workflow means an imperfect first draft is not an outage.
• Distribution support out of the box — the kernel side is mainline and the tooling is packaged everywhere that matters, so hardening does not require a custom kernel or a proprietary module.
• Complements, rather than replaces, other controls — AppArmor sits on top of DAC and works alongside firewalling, audit logging and integrity checking to build defence in depth.

Use Cases

• Hardening internet-facing services — confine Nginx, PostgreSQL, NSD/Unbound or a mail server so that only their configuration, data and log directories are reachable, and watch the denial stream for attempts to read /etc/shadow or write outside the document root.
• Repeatable server baselines — ship profiles as files (with #included local overrides) through Ansible, Puppet or a cloud-init script so every host in a fleet carries the same confinement, versioned beside the rest of the configuration.
• Sandboxing desktop applications — distributions ship profiles for browsers, office suites, chat clients and video-conferencing tools, limiting what a malicious document or a compromised renderer can touch in a user’s home directory.
• Containers and snaps — container runtimes and snapd generate AppArmor policy per container or snap, and snapd vendors the AppArmor userspace tarball so confinement is applied even where the host carries an older version.
• Restricting an unprivileged user namespace — recent userspace releases support confining processes that create user namespaces, a useful mitigation for sandbox-escape style bugs.

Platforms

Linux only — AppArmor is a kernel LSM, with the kernel portion mainlined since 2.6.36 and the userspace maintained separately. The current userspace works with any kernel from 2.6.15 onwards (older kernels need the project’s compatibility patches) and is packaged by Debian/Ubuntu (apparmor, 4.1.0 in Debian 13), openSUSE/SUSE, Alpine and other distributions, with builds for amd64, arm64, armhf/armel, i386, ppc64el, s390x and riscv64. It builds from source as several components — libapparmor, binutils, the parser, the initscripts, the Python utilities and the reference profiles/ tree — and ships language bindings for C, Perl, Python and Ruby.

Licence and Website

Free and open source. The kernel module and the userspace tools are released under the GNU General Public License v2.0 — the repository’s LICENSE file states that the GPL applies to the whole source tree unless a subdirectory says otherwise. libapparmor is an explicit exception, licensed LGPL so that non-GPL binaries can still use the confinement APIs. Source, releases and the issue tracker are at gitlab.com/apparmor/apparmor, and the official documentation (concepts, profile syntax, abstractions, man pages) is at apparmor.net. Recent releases are 5.0.2 (July 2026) on the current feature line and 4.1.8 (August 2026) on the maintenance line, with 6.0.0 in alpha.

Alternatives

• Firejail — user-space sandboxing built on namespaces and seccomp-bpf, with AppArmor profiles for common desktop applications
• auditd — the Linux Audit System daemon, which records the denial events AppArmor produces
• Falco — runtime threat detection over syscall and Kubernetes audit streams
• Lynis — security auditing and hardening checks for Unix-like systems
• Browse more security and privacy tooling in the directory