Learn AppArmor - Basic Concepts & Core Architecture

#Introduction

In episode 1 we traced AppArmor's history: why the world needs MAC, its birth at Immunix, and its mass adoption by Ubuntu, Debian, Docker, and even ChromeOS. Now it's time to understand how AppArmor actually works underneath. This episode is the technical foundation: every episode after this one will stand on the concepts we build here.

Three things we'll master: the concept of a profile as AppArmor's policy unit, the modes that determine whether rules are enforced or merely logged, and the architecture that connects the kernel with the userspace tools. After this episode, you'll be able to explain to anyone what AppArmor is without opening the documentation.

#The Profile Concept: Policy per Application

AppArmor's basic unit is the profile — a set of rules attached to a single application (executable) that determines what its descendant processes may do. Profile names usually follow the executable's path, e.g. /usr/sbin/nginx. The analogy: a profile is an employee's employment contract — before entering the building, the employee is handed a contract stating which rooms they may enter, which documents they may read, and which equipment they may use.

An AppArmor profile governs several access dimensions:

The most important principle to internalize: a process without a profile is an invulnerable process. If an application has no profile at all, AppArmor restricts nothing — it runs exactly as if there were no MAC. Security value appears precisely when we give it a profile. This differs from some other MAC systems that try to label every object.

#File Rules: r, w, m, k

In the file dimension, AppArmor recognizes four basic accesses you'll keep encountering:

m is often the source of confusing denials for beginners: a program may be allowed to execute its binary, but fails to run because a library isn't allowed to be mmaped. We'll dig deeper into this in episode 4 when we write profiles.

#Enforce vs Complain Modes

Every profile runs in one of two modes:

• Enforce mode — rules are actually enforced. Access that isn't allowed is denied and recorded in the logs. This is the default mode for profiles you trust.
• Complain mode — rules are read, but not enforced. Access that isn't allowed still succeeds, but is recorded as a violation in the logs. Ideal for learning mode while building a new profile.

A fitting analogy: enforce is a friend who holds you back when you try to enter a forbidden room, while complain is a friend who only logs every door you try to open without holding you back — then hands you a report at the end of the day. That log is the raw material for perfecting the profile.

Complain mode is one of AppArmor's biggest advantages for production: you can launch an application with a new profile in complain mode, collect its real behavior over several days, then promote it to enforce with confidence.

#AppArmor vs SELinux: Path-based vs Type-based

This is the question that comes up most often in the community: why isn't AppArmor SELinux? The answer lies in the decision basis:

• AppArmor is path-based. Rules are written as file paths, e.g. owner /etc/nginx/nginx.conf r. When a process accesses a file, the kernel compares that file's path with the profile rules. Easy to understand and write because it directly mirrors the filesystem structure.
• SELinux is label/type-based. Every object (file, process, port, socket) is given a labeled security context, and rules are written as process-label/object-label pairs. More expressive for non-file objects, but more complex: you have to ensure file labels are correct in addition to writing the rules.

This comparison isn't about which is "better" — both are proven MAC systems. The question is context: in a path-based ecosystem (Debian/Ubuntu), AppArmor is the natural choice. And remember, both can coexist on one system through modern LSM stacking.

#Architecture: Kernel LSM + Userspace

AppArmor consists of two worlds working together:

#The Kernel: AppArmor LSM

On the kernel side, AppArmor is implemented as a Linux Security Module (LSM). The LSM is a framework of security hooks in the kernel that gets called on every sensitive operation: opening a file, creating a socket, calling mount, and so on. The AppArmor hook checks the active process profile — if one exists, the decision is made from the rules; if not, the operation is allowed through.

The kernel exposes two important areas:

• /sys/kernel/security/apparmor — securityfs where the kernel publishes status and loaded profiles, and where userspace writes policy.
• Compiled profile storage in cache — compiled profiles are stored so subsequent loads are faster.

#Userspace: apparmor_parser, aa-status, libapparmor

On the userspace side, three main components:

The source of truth lives in /etc/apparmor.d/ — the directory where all text profile files are stored. At system boot (or when you run apparmor_parser), the profiles in this directory are compiled and loaded into the kernel. The full flow:

/etc/apparmor.d/nginx
      │  ditulis sebagai teks
      ▼
apparmor_parser (kompilasi + load)
      │
      ▼
Kernel LSM (memuat aturan ke memori)
      │
      ▼
Hook LSM menilai akses proses terhadap path

This is the flow you'll rely on in episodes 3 and 4: writing profiles in /etc/apparmor.d/, loading them with apparmor_parser, then verifying with aa-status.

#Common Pitfalls

1. Assuming a process without a profile is already safe. Completely wrong — a process without a profile isn't restricted at all. AppArmor's value lives in the profiles you give it.
2. Thinking m is the same as r. m allows memory-mapping a file — critical for libraries. Without m, a program can fail to run even when r is allowed.
3. Going straight to enforce without complain. Writing a new profile and enforcing it immediately without watching its real behavior is a recipe for mysterious application errors. Use complain first.
4. Treating AppArmor and SELinux as identical. Both are MAC, but their bases differ: path vs label. Understanding the difference saves you from confusion when moving between distros.

#Conclusion

In episode 2 we built AppArmor's technical foundation: the profile concept as the per-application policy unit, the r w m k file rules plus other dimensions like network, capabilities, mount, ptrace, and signals; the two working modes, enforce and complain; the path-based vs type-based comparison with SELinux; and the kernel LSM architecture with the userspace components apparmor_parser, aa-status, and libapparmor.

The core takeaways:

• Profile = an application's employment contract — it determines the files, network, capabilities, and signals it may access.
• No profile = no restrictions. Security value is born from giving a profile.
• Enforce denies, complain only records — complain mode is the gateway to a mature profile.
• AppArmor is path-based, SELinux is type-based — the decision basis that sets them apart.
• Profiles originate in /etc/apparmor.d/, are processed by apparmor_parser, and verified with aa-status.

In episode 3, we move to our first hands-on practice: status, modes, and loading/unloading profiles — reading full status with aa-status, checking whether AppArmor is active with aa-enabled, switching enforce/complain modes, and loading and unloading profiles with apparmor_parser. Keep your momentum, because starting with this episode you're touching AppArmor directly!