Frequently Asked Question

SELinux or AppArmor, what is the practical difference?

Both SELinux and AppArmor are Linux Security Modules (LSMs) that add mandatory access control on top of the classic Unix permissions. They differ chiefly in how they identify the objects a process may touch. SELinux uses security labels: every file, socket, process, and port carries a context like system_u:object_r:httpd_sys_content_t:s0 stored in extended attributes, and the policy reasons about those labels. AppArmor uses pathnames: a profile lists the file paths a confined program may read, write, execute, or otherwise touch.

The label-based model is more rigorous, a renamed or hard-linked file still carries the same context, so the policy is harder to bypass, but it makes the policy harder to write and the system harder to debug when things go wrong. Path-based AppArmor profiles are easier to read and edit (/etc/apparmor.d/usr.sbin.nginx is mostly legible without a manual), at the cost of some edge cases around symlinks and mount namespaces. RHEL, Fedora, and CentOS ship SELinux in enforcing mode by default; Ubuntu, Debian, and openSUSE ship AppArmor.

The defender's practical advice is to use whichever your distribution ships with, leave it in enforcing mode, and learn the handful of commands that let you diagnose denials: ausearch -m avc and audit2allow for SELinux, aa-status and aa-logprof for AppArmor. Turning either of them off because an application "doesn't work" is almost always the wrong fix.