Don't Panic — AppArmor

AppArmor does not protect a system from its users. It protects a system from a program the system runs on purpose.

The observation underneath is that a Unix process inherits the entire authority of the account it runs as, which for a background service is wildly more than the job calls for — a few config files, a socket, one state directory, and nothing else on the machine is its business. A profile writes down that shorter list, and the kernel enforces it after the ordinary file permissions have already said yes.

That "after" is the whole posture. Nothing here replaces file ownership, permission bits, capabilities or patching: every applicable layer must permit an operation before it happens, and this one only ever subtracts.

The mechanism is short: a process asks the kernel for an operation, the kernel finds the profile attached to that program's path, and a rule either permits it or does not. Policy is allow-list shaped, so an enforcing profile with no matching rule denies by default.

Complain mode records the operation and permits it anyway — how a profile gets developed, and not a form of protection.

Rules match paths. r for read, w for write, m to map a file as executable memory, then the execution rules: ix keeps the current profile, px switches to another, cx enters a child profile, ux drops confinement altogether. Those four decide what confines the next program, so they deserve more scrutiny than anything else in the file. Treat ux as an exit, not an option.

Two things will surprise you. The first is that path-based policy is only as stable as the filesystem beneath it. Hard links and bind mounts — a second name for one file, a directory grafted into a second location — can present the same file at a path no profile mentioned.

Upstream concedes the shape of this: where reading the source and writing the destination are both allowed, a rename restriction can be sidestepped by copying the contents. Systems that tag objects themselves rather than their paths have no such problem — but what AppArmor buys in exchange is legibility, since a competent administrator reads one of these profiles in a minute and will not read the equivalent SELinux policy in an hour. Spend the effort on the layers underneath instead.

The second surprise is that confinement assumes those layers hold. The CAP_SYS_ADMIN privilege includes mounting filesystems, and path rules are evaluated against whatever the process currently sees mounted — so anything able to remount can change what a path resolves to and walk around its own profile without ever violating it. Production workloads drop that privilege for exactly this reason.

One habit worth taking away: run aa-status and read the complain count rather than the loaded count. A profile parked in complain mode breaks nothing and alerts nobody, so it stays there for years after the incident that moved it. Broad coverage with a large complaining share gives all the audit noise of confinement and none of the protection.

The Cheatsheet is the reference for rule syntax and tooling, and the Intro walks the profile lifecycle end to end. Save Field Notes for last: it covers what changed in 2024, since when this denies things on hosts where nobody wrote a rule.