Linux has two major mandatory access control (MAC) frameworks: SELinux and AppArmor. Both enforce security policies beyond standard discretionary access control (DAC), but they use fundamentally different approaches. SELinux uses type enforcement on labeled objects. AppArmor uses path-based restrictions on named files. This difference has deep implications for security, usability, and the kinds of attacks each system can prevent.
SELinux assigns a security label to every object in the system - files, processes, ports, sockets, devices. The label is stored as an extended attribute on the filesystem (for files) or in kernel data structures (for processes and ports). The policy defines which type labels are allowed to interact and in what ways.
When httpd (running as httpd_t) tries to read a file labeled httpd_sys_content_t, the kernel checks the policy. If there is an allow rule for that combination, access is granted. If not, it is denied and logged.
The critical property of this design is that labels follow the object, not the path. If you move a file from /var/www/html/ to /tmp/, it keeps its httpd_sys_content_t label. If you create a hard link to the file in another directory, the link has the same label. The security context is a property of the inode, not the path string.
AppArmor confines programs using profiles that specify which file paths a program can access. A profile for Apache might say:
This is easier to read and write than SELinux policy. The profile lists paths and permissions in a straightforward format. You do not need to understand type labels, role transitions, or the policy compilation toolchain.
However, the path-based approach has a structural weakness. If an attacker can create a hard link or mount a bind mount to make a restricted file appear at an allowed path, AppArmor may grant access that should have been denied. The security decision depends on the name used to access the file, not the file itself.
| Feature | SELinux | AppArmor |
|---|---|---|
| Access control model | Type enforcement (label-based) | Path-based profiles |
| Label storage | Extended attributes on inodes | No labels - paths only |
| Policy scope | System-wide - every object labeled | Per-program profiles |
| Default stance | Deny all unless explicitly allowed | Unconfined unless a profile is loaded |
| Hard link safety | Labels follow the inode | Paths can be manipulated |
| MLS/MCS support | Full multi-level and multi-category | Not supported |
| Network controls | Port labels and socket types | Basic network rules |
| Default distro | RHEL, CentOS, Fedora, Rocky, Alma | Ubuntu, SUSE, Debian |
| Learning curve | Steep | Moderate |
| Container integration | svirt, MCS labels per container | Profile per container |
Multi-tenant and container environments. SELinux MCS labels assign a unique category to each container or virtual machine. Even if two containers run the same image with the same binary, they cannot access each other's files because their labels differ. AppArmor can confine containers with profiles, but it cannot provide the same level of isolation between containers running the same application.
Systems requiring formal security certification. SELinux was developed by the NSA and has been evaluated under Common Criteria and used in environments that require formal security validation. The MLS policy supports Bell-LaPadula confidentiality enforcement. If your compliance requirements mention labels, classification levels, or mandatory access control by name, SELinux is typically the expected implementation.
Defense against privilege escalation chains. Because SELinux labels every object and enforces policy system-wide, an attacker who compromises one service cannot easily pivot to another. Even if they gain code execution inside httpd_t, the type enforcement policy prevents that process from reading shadow_t files, connecting to postgresql_port_t ports, or executing binaries labeled bin_t unless the policy explicitly allows it.
Filesystem-independent security. SELinux labels are stored in extended attributes, which means they survive file copies (when using tools that preserve xattrs), backups, and transfers between systems. The security context is a property of the data, not its location. Path-based systems lose their protection the moment a file moves to an unexpected location.
Rapid profile development. AppArmor profiles are human-readable text files. Creating a new profile involves running the application in complain mode, using aa-genprof to observe its access patterns, and reviewing the generated rules. The entire process can take minutes. Writing equivalent SELinux policy from scratch takes significantly longer.
Workloads on Ubuntu/Debian systems. AppArmor is deeply integrated into Ubuntu and its derivatives. Snap packages use AppArmor profiles for confinement. Running SELinux on Ubuntu is possible but unsupported by Canonical and requires significant effort to set up.
Teams without SELinux expertise. The learning curve for SELinux is real. If your team does not have the time or inclination to learn type enforcement, running AppArmor with good profiles is better than running SELinux in permissive mode (which provides no security) or disabling it entirely.
SELinux provides stronger security guarantees through type enforcement. Its label-based model is more robust against path manipulation, provides true multi-level security, and offers finer-grained control over process isolation. The cost is complexity - both in learning and in day-to-day troubleshooting.
AppArmor is easier to adopt and maintains. Its path-based model is intuitive and its tooling is approachable. For many workloads, especially on Ubuntu-based systems, it provides adequate mandatory access control with lower operational overhead.
If you are running RHEL, CentOS, Fedora, Rocky Linux, or AlmaLinux, SELinux is already there. It is already in enforcing mode by default. Learn it instead of disabling it. That is what this game is for.