AppArmor vs SELinux: What Is the Difference?
Compare AppArmor and SELinux Mandatory Access Control on Linux — path-based vs label-based enforcement — with a DevOps interview answer.
Expected Interview Answer
AppArmor and SELinux are both Linux Mandatory Access Control (MAC) systems that restrict what a process can do beyond standard user permissions, but AppArmor confines processes by file path using human-readable profiles, while SELinux labels every process and object with a security context and enforces a much stricter, label-based policy that also governs ports, capabilities, and inter-process transitions.
Both sit on top of the Linux Security Modules (LSM) framework and add a second layer of enforcement after standard discretionary access control (owner/group/other permissions) has already allowed an action. AppArmor profiles are simple text files keyed to a binary’s path, listing exactly which files, capabilities, and network operations that binary may use, which makes them fast to write and easy to read, but path-based confinement is weaker against tricks like hard links or bind mounts. SELinux instead tags every process and file with a type/context (for example httpd_t or var_log_t) and a central policy defines which types may interact with which, giving finer-grained, path-independent control at the cost of a steeper learning curve and denser policy language. In practice, Ubuntu and SUSE default to AppArmor for its simplicity, while RHEL, Fedora, and CentOS default to SELinux for its stronger guarantees in regulated environments; container runtimes like Docker and Kubernetes can layer either one as an additional profile on top of seccomp and Linux capabilities.
- Limits blast radius if a process is compromised
- Enforces least privilege beyond standard file permissions
- Blocks privilege escalation even for root-owned processes
- Required baseline for many compliance and hardening standards
AI Mentor Explanation
AppArmor is like a ground pass that lists the exact gates, nets, and dressing rooms a specific player may enter by name, written in plain language security can read at a glance. SELinux is like a colour-coded wristband system where every person and every room carries a label, and a central rulebook decides which coloured wristbands may enter which coloured rooms regardless of the gate they came through. The wristband system catches a groundstaff member sneaking into the players’ area through a side door that a simple gate-list would miss, because the room itself checks the label, not just the entrance used. Both stop unauthorised access, but the wristband rulebook is stricter and needs a security officer trained to maintain it.
Step-by-Step Explanation
Step 1
Pick the model for the distro
Ubuntu/SUSE ship AppArmor by default; RHEL/Fedora/CentOS ship SELinux by default.
Step 2
Author or generate a policy
AppArmor uses per-binary path profiles (aa-genprof helps draft them); SELinux uses type-labelled policy modules.
Step 3
Run in permissive/complain mode
Log violations without blocking to validate the policy against real workload behaviour first.
Step 4
Enforce and monitor
Switch to enforcing mode and watch audit logs (auditd/journalctl) for denials that indicate a policy gap.
What Interviewer Expects
- Understanding both are LSM-based Mandatory Access Control systems
- Knowledge that AppArmor is path-based and SELinux is label-based
- Awareness of which distros default to which system
- Ability to explain why label-based control resists path-based bypass tricks
Common Mistakes
- Saying one replaces standard Unix file permissions instead of layering on top
- Claiming AppArmor and SELinux can both be fully enforcing on the same kernel simultaneously
- Confusing SELinux contexts with simple user/group permissions
- Not mentioning permissive/complain mode as the safe rollout step before enforcing
Best Answer (HR Friendly)
“Both AppArmor and SELinux add an extra security layer on Linux that limits what a process can do even if it is compromised. AppArmor is simpler — it names a program and lists what files and actions it is allowed to touch — while SELinux tags everything with a security label and enforces stricter rules centrally, which is why regulated environments like RHEL-based production systems often prefer it despite the steeper learning curve.”
Code Example
# AppArmor: list loaded profiles and their mode
sudo aa-status
# Put a profile into complain (log-only) mode while testing
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
# SELinux: check current enforcement mode
getenforce
# SELinux: show the security context/label of a process
ps -eZ | grep nginx
# SELinux: check recent denials
sudo ausearch -m avc -ts recentFollow-up Questions
- Can AppArmor and SELinux both be enforcing on the same running kernel?
- How would you debug a denied action under SELinux enforcing mode?
- How do container runtimes like Docker apply AppArmor or SELinux profiles?
- What is the difference between MAC and DAC (discretionary access control)?
MCQ Practice
1. How does AppArmor primarily confine a process?
AppArmor profiles are keyed to a program's path and list which files, capabilities, and network actions that binary may use.
2. What makes SELinux resistant to path-based bypass tricks like symlinks?
SELinux enforces policy based on the security context/label attached to processes and objects, not the path used to reach them.
3. Which mode lets an administrator observe policy violations without blocking them?
Permissive mode (SELinux) or complain mode (AppArmor) logs would-be denials so a policy can be validated before it is enforced.
Flash Cards
What kernel framework do AppArmor and SELinux both build on? — Linux Security Modules (LSM).
How does AppArmor confine processes? — By file path, via per-binary text profiles.
How does SELinux confine processes? — By security label/type attached to every process and object.
Which distros default to SELinux vs AppArmor? — RHEL/Fedora/CentOS default to SELinux; Ubuntu/SUSE default to AppArmor.