SELinux and AppArmor

SELinux and AppArmor are both Linux Security Modules (LSM) — kernel hooks that add a mandatory access control (MAC) layer on top of the ordinary owner/group/rwx permissions every Linux process already obeys. The standard permissions are discretionary: the file's owner decides who gets access, and a process running as root bypasses them entirely. A MAC layer adds a second, non-negotiable verdict written by the administrator into kernel-enforced policy, and that verdict can deny an action even when the file permissions would allow it and even when the process is root.

The operational point is containment. When a network-facing daemon is compromised, MAC is what stops the attacker pivoting from "I own the web server process" to "I read /etc/shadow and wrote a cron job." Ubuntu and Debian ship AppArmor enabled by default; RHEL, Fedora, and their derivatives ship SELinux. They solve the same problem with very different models — AppArmor confines a binary by the file paths it may touch, SELinux labels every process and object and checks the labels — and that difference dictates how you debug a denial.

Discretionary versus Mandatory Access Control

Classic Unix permissions are discretionary access control: the owner sets the bits, the owner can hand out access, and UID 0 is exempt. That model is fine for keeping users out of each other's files, but it offers nothing once a privileged process is hijacked. An attacker who lands code execution inside a root-owned daemon inherits every capability that daemon had — which, with DAC alone, is the whole machine.

MAC inverts the trust. Policy is written once by the administrator and the kernel enforces it on every relevant syscall, regardless of UID. A confined Nginx process may be permitted to read /var/www and bind port 443 and nothing else; if exploited, an attempt to read /etc/shadow or open an outbound socket to a C2 host is denied by the kernel, logged, and the breach is boxed into the daemon's intended job. The trade-off is that policy must describe the legitimate behavior accurately — too tight and the service breaks, too loose and the confinement is theater.

AppArmor

AppArmor is path-based. Each confined program gets a profile in /etc/apparmor.d/ named after the binary's full path (for example usr.sbin.nginx), listing the files it may read, write, or execute and the capabilities it may use. A profile runs in one of two modes: enforce, where violations are blocked and logged, or complain, where violations are allowed but logged so you can see what a real workload needs before you tighten it.

Day-to-day work is a handful of commands. aa-status shows which profiles are loaded and in which mode; aa-complain and aa-enforce flip a single profile between modes; aa-genprof generates a starter profile by watching a binary run, and aa-logprof walks the recent denials and proposes profile edits interactively.

# list loaded profiles and their modes
sudo aa-status

# put one profile into complain mode to learn what it needs
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# after running real traffic, review denials and update the profile
sudo aa-logprof

# tighten back to enforce
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Because profiles key on paths, AppArmor is quick to read and quick to reason about — a profile is essentially an allow-list of files. The cost of that simplicity is that it follows paths, not data: a file reachable through two different paths (a bind mount, a hard link, a symlink the policy didn't anticipate) can slip the rules, which is exactly the gap SELinux's labeling closes.

SELinux

SELinux is label-based. Every process and every object — files, sockets, ports, directories — carries a security context of the form user:role:type:level, and the core mechanism, type enforcement, decides access by checking the process's type against the object's type in a compiled policy. The label travels with the object on disk (stored in the security.selinux extended attribute), so renaming or hard-linking a file does not change what may touch it. See contexts with ls -Z for files and ps -Z for processes.

SELinux has three system states: enforcing (policy is applied and violations blocked), permissive (violations are logged but allowed — the learning and debugging mode), and disabled (the LSM is off entirely). getenforce prints the current state and setenforce 1/setenforce 0 toggles between enforcing and permissive at runtime; the boot default lives in /etc/selinux/config.

# current mode and file/process contexts
getenforce
ls -Z /var/www/html
ps -Z

# move to permissive to debug, then back to enforcing
sudo setenforce 0
sudo setenforce 1

# reapply the correct labels after moving files into place
sudo restorecon -Rv /var/www/html

Most tuning never touches custom policy. semanage fcontext registers the correct type for a path so future relabels stick; restorecon resets a file's label to what policy expects; and SELinux booleans — toggled with setsebool -P — switch whole behaviors on or off, such as httpd_can_network_connect to let a web server make outbound connections. When no boolean or fcontext fits, audit2allow reads the denial records and generates a custom policy module, but that is the last resort, not the first.

Troubleshooting Denials

A MAC denial looks like a permission error that chmod and chown cannot fix, because the file permissions were never the problem. Both systems log every denial, and reading those logs is the entire skill. AppArmor writes apparmor="DENIED" lines to the kernel log (dmesg) and, where auditd is running, to /var/log/audit/audit.log. SELinux writes AVC (access vector cache) denial records to /var/log/audit/audit.log; ausearch -m avc -ts recent and sealert turn them into readable diagnoses with suggested fixes.

# AppArmor denials
sudo dmesg | grep -i apparmor

# SELinux AVC denials, with human-readable advice
sudo ausearch -m avc -ts recent
sudo sealert -a /var/log/audit/audit.log

The fix is almost never to switch the whole system off. The correct loop is: reproduce the denial, read the log, and address the specific access — relabel with restorecon, flip a boolean, add a path to an AppArmor profile via aa-logprof, or generate a narrow module with audit2allow. Disabling MAC to "unblock" a single service throws away the protection for every other service on the box, and on SELinux a system that booted disabled then re-enabled will have unlabeled files that need a full filesystem relabel (touch /.autorelabel; reboot) before it works correctly.