AppArmor vs SELinux: Which Linux MAC System Should You Use?

If you are hardening a Linux machine, you eventually hit a fork in the road: AppArmor or SELinux. Both are Mandatory Access Control (MAC) systems built into the Linux kernel through the same Linux Security Modules (LSM) framework. Both confine a compromised process so that an exploit cannot freely reach the rest of your system. But they take very different approaches, and the right choice depends less on which is “more powerful” and more on what you run, which distro you use, and how much policy work you are willing to do.

This guide compares them by design, by daily maintenance cost, and by threat model — so you can decide rather than guess.

What Mandatory Access Control actually does

Standard Linux permissions are discretionary: the owner of a file decides who can read or write it, and a process runs with all the permissions of the user who launched it. If that process is exploited, the attacker inherits those permissions — your files, your network, your home folder.

Mandatory Access Control adds a second layer the user cannot override. A central policy, enforced by the kernel, decides what each process is allowed to do regardless of file ownership. A web server confined by MAC can be told it may only read its own document root and listen on port 443 — and even if an attacker takes it over, the kernel still refuses anything outside that envelope.

AppArmor and SELinux both deliver this. The difference is how they identify what a process is allowed to touch.

The core design difference: paths vs labels

This single distinction explains almost every practical trade-off between the two.

AppArmor is path-based. A profile names the actual filesystem paths a program may access. A rule like /etc/nginx/** r means “nginx may read anything under /etc/nginx”. This maps directly onto how administrators already think about a system, which makes profiles readable and quick to write.

SELinux is label-based. Every file, process, socket, and port carries a security context (a label) such as httpd_sys_content_t. Policy rules describe which labels may interact with which — not which paths. The path /var/www/html/index.html is irrelevant to SELinux; what matters is the label attached to it.

The consequence: if you move a file in AppArmor, the rule still applies as long as the new path is covered. If you move a file in SELinux, it can keep or lose its label depending on how it was moved (cp vs mv behave differently), which is the single most common source of “it worked until I copied the file” confusion. The flip side is that label-based policy is harder to fool — an attacker cannot bypass a rule simply by reaching the same data through a symlink or an alternate path, because the label travels with the object.

Granularity and assurance

SELinux is the more fine-grained of the two. Because every object is labeled, policy can express controls AppArmor cannot — multi-level security, type enforcement across hundreds of domains, and constraints that separate, say, two web applications that both live under /var/www but should never read each other’s data. This is why SELinux is the default in environments with formal security requirements (RHEL, Fedora, and government-influenced deployments) and why it was originally developed with the United States National Security Agency.

AppArmor is deliberately coarser. It cannot express everything SELinux can, but for the common goal — confining a handful of network-facing services and browsers so a single exploit cannot pivot — that ceiling rarely matters. Most desktop and small-server threat models are fully served by AppArmor’s expressiveness.

A useful way to frame it: SELinux gives you a higher ceiling; AppArmor gives you a lower floor of effort. Which one wins depends entirely on whether you actually need the ceiling.

Maintenance cost in the real world

This is where the choice is usually decided.

With AppArmor, profiles are short text files you can read and edit by hand. Distros that default to it (Ubuntu, Debian, openSUSE) ship pre-written profiles, and you can generate new ones interactively:

# See which profiles are loaded and in which mode
sudo aa-status

# Generate a profile for a new application by watching it run
sudo aa-genprof /usr/bin/myapp

# Put a profile into enforce mode
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

A “complain” mode logs violations without blocking them, which makes it safe to develop a profile on a live system and tighten it once you know what the app legitimately needs.

With SELinux, the policy is large and you almost never write it from scratch — you adjust booleans and relabel files. The friction point is diagnosing denials. The wrong reflex is to run setenforce 0 and turn it off; the right one is to read the audit log:

# Check the current mode
getenforce

# Investigate recent denials and get suggested policy
sudo ausearch -m avc -ts recent | audit2allow -a

# Restore the correct labels on a path
sudo restorecon -Rv /var/www/html

audit2allow proposes a policy module that would permit the denied action; you review it before applying so you understand why the denial happened rather than blanket-allowing it. This workflow is powerful but has a real learning curve, and it is the main reason administrators disable SELinux instead of learning it — which throws away the protection entirely.

Follow the distribution default

In practice the strongest recommendation is the simplest: use whichever MAC system your distribution ships and supports.

Fighting the default means running an unsupported configuration: AppArmor profiles for Fedora’s packages are not maintained, and SELinux policy for Ubuntu’s package layout is incomplete. You inherit a maintenance burden the distribution will not help you carry. On a Fedora or RHEL box, leave SELinux in Enforcing mode and learn audit2allow. On Ubuntu or Debian, keep AppArmor enabled and make sure your browser and network services run with enforce-mode profiles.

This is the same principle behind picking a secure Linux distribution at all: the protection that is actually maintained beats the protection that is theoretically stronger but unsupported on your system.

Where MAC fits in a layered defense

Neither AppArmor nor SELinux is a complete security strategy. MAC confines processes that are already running; it does nothing about untrusted code you choose to execute, or about isolating whole workloads from each other. For per-application isolation on the desktop, application sandboxing tools such as Firejail and bubblewrap work alongside MAC rather than replacing it. For broader system hardening — kernel parameters, sysctl, verified boot — MAC is one layer in the wider Linux hardening picture, and it sits within the larger comparison of Linux versus Windows security models.

The takeaway is that the AppArmor-versus-SELinux question is real but narrow. Pick the one your distro maintains, leave it in enforcing mode, and spend your remaining effort on the layers above and below it.

Frequently asked questions

Is SELinux more secure than AppArmor? SELinux can express stricter and more fine-grained policy, so in absolute terms its ceiling is higher. But security comes from policy that is actually enforced and maintained. An AppArmor system left in enforce mode protects you more than an SELinux system someone disabled because the denials were confusing.

Can I run both at the same time? No. AppArmor and SELinux are both “major” LSMs and the kernel loads only one as the primary MAC system. You choose one per machine — in practice, the one your distribution defaults to.

Should I ever disable them? Almost never. Disabling MAC removes a layer that contains the blast radius of an exploited service. If you hit a denial, diagnose it (audit2allow for SELinux, complain mode for AppArmor) instead of switching the whole system off.

Which is easier for a beginner? AppArmor. Its path-based profiles read like the filesystem you already understand, and Ubuntu and Debian ship working profiles out of the box. SELinux rewards the time you invest in learning it, but that time is real.