AppArmor: Path-Based Mandatory Access Control

Ordinary Linux permissions are discretionary (DAC): a file's owner decides who may read or write it, and a process gets whatever its user is allowed. A hijacked tcpdump running as root can therefore read every file root can read, which is all of them.

AppArmor adds mandatory access control (MAC): for each confined program, the administrator writes a profile, a list of exactly what that program may touch. The kernel checks the profile after the normal permission check passes, and the program cannot opt out. Think of the profile as a guest list for one program. DAC asks whether the user may open the door; AppArmor asks whether this program is on the list for this path. A compromised tcpdump can still write .pcap files, but it can't read /etc/shadow, because no rule in its profile grants that path.

Ubuntu and Debian turn AppArmor on by default; RHEL and Fedora use SELinux. Both are MAC, but they decide differently:

• AppArmor is path-based. Rules name files by path: /var/lib/notesd/state.db rw,. Only the confined programs have profiles, and everything else runs unconfined.
• SELinux is label-based. Every file and process carries a label (a context such as httpd_sys_content_t), and the policy matches labels, not paths. If you move a file, it keeps its label.

The practical consequence: in AppArmor, where a file is decides access. There's no restorecon and no relabelling, because there are no labels. A file copied into a path the profile allows becomes readable at once, and a file moved out of it becomes unreadable.

Every profile is a text file in /etc/apparmor.d/. By convention the file is named after the program's path with the slashes turned into dots: the profile for /usr/sbin/mysqld lives in /etc/apparmor.d/usr.sbin.mysqld. The parser doesn't enforce the convention, but every tool and every admin expects it.

The directory also holds the pieces profiles are built from and the switches that change their mode:

• abstractions/ holds reusable rule sets (base, nameservice, user-tmp) that profiles pull in with #include.
• tunables/ holds variables such as @{HOME} and @{PROC}.
• local/ holds site additions to shipped profiles (more below).
• disable/ holds symlinks to profiles that must not load.
• force-complain/ holds symlinks to profiles that must load in complain mode.

A file rule is a path, a space, the permissions, then a comma: /etc/notesd/notesd.conf r,. The permission letters are:

• r read, w write, a append only (it can't be combined with w);
• m map the file executable (needed for the program's own binary and its libraries);
• k lock, l link;
• x execute, which always needs a qualifier saying which profile the child runs under: ix inherits this profile, px switches to the child's own profile, cx switches to a child profile, and ux runs it unconfined. An uppercase Px/Ux also scrubs dangerous environment variables like LD_PRELOAD.

Paths can glob: * matches within one directory level, ** matches across levels, and {a,b} matches either word. Two qualifiers change a rule's meaning. deny forbids the access even if another rule allows it, and doesn't log it. owner applies the rule only to files the process's user owns.

You'll build a small profile for a made-up service, notesd, in a practice directory, ~/aa-lab. It's the same shape as the profiles in the labs.

A loaded profile runs in one of two modes, and a third state keeps it from loading at all:

• Enforce (the default): accesses the profile doesn't grant are blocked and logged as apparmor="DENIED".
• Complain: nothing is blocked, but every access the profile would refuse is logged as apparmor="ALLOWED". This is the tuning mode, the counterpart of SELinux's permissive mode, except it applies to one profile instead of the whole system.
• Disabled: the profile isn't loaded, so the program runs unconfined.

Those tools only edit files you can edit yourself, then reload. You can make the same change by hand, which is also how you do it on a host without apparmor-utils. Complain mode is a flag on the header line. Try it on the practice copy in ~/aa-lab.

Every AppArmor decision worth logging becomes a kernel audit message with type=1400. Where it lands depends on the host:

• with auditd running, in /var/log/audit/audit.log as type=AVC msg=audit(...): apparmor="DENIED" ...;
• without it, in the kernel log: dmesg, journalctl -k, and on Ubuntu also /var/log/kern.log and /var/log/syslog.

The line is a list of key="value" pairs, so you don't need a special tool to read it, just grep. The practice file below is a kernel log from a host where notesd is denied, plus two lines that aren't denials.

The right fix is the narrowest rule that grants the denied access: the exact path from name= with the letters from requested_mask. Don't switch the profile to complain, and don't grant /var/lib/** rw,. Both make the error go away by confining less. The rule goes inside the braces, and order doesn't matter: AppArmor combines every rule in the profile, then subtracts the deny rules.

The two AppArmor labs plant profiles in /etc/apparmor.d and give you an assignment or a denial. Inside one of them, run these reads before you change anything. Say what each one tells you: which profile, which header line, which path and which access. The fix is then a single edit.