Ubuntu ships AppArmor and RHEL ships SELinux as their mandatory access control system. What is the fundamental difference in how each one identifies the things it is protecting, and what practical consequences does that difference have?

## Same job, two different naming schemes Both AppArmor and SELinux are Linux Security Modules that implement mandatory access control: a second check, after the classic owner/mode check, that the resource's owner cannot relax. They differ in how they *name* the things they are talking about, and almost every practical difference falls out of that one choice. **AppArmor names objects by pathname.** A profile is a text file, conventionally `/etc/apparmor.d/usr.sbin.nginx` for `/usr/sbin/nginx`, that attaches to an executable and enumerates path rules with permission letters, plus rules for capabilities and network access. A program that has no profile is unconfined — confinement is opt-in, program by program. **SELinux names objects by label.** Every process runs in a domain and every file, directory, socket and port carries a type. The file's type lives in the `security.selinux` extended attribute on the inode. The policy is one system-wide compiled ruleset of allow rules over `(domain, type, class, permission)` tuples, and under the targeted policy anything not covered is confined by a catch-all unconfined domain rather than being ignored. ## What follows for the administrator **Readability and authorship.** An AppArmor profile can be read and edited by anyone who understands file paths, and the tooling (`aa-genprof`, `aa-logprof`) will walk you through building one from observed behaviour. SELinux policy is a compiled artifact; you interact with it through booleans, labels and generated modules rather than by editing rules directly. This is the single biggest reason Ubuntu-family shops find AppArmor approachable. **Identity of the protected object.** Because a SELinux label rides on the inode, it survives renames and hard links and applies no matter which path reached the file. Because AppArmor matches on the resolved pathname, a file exposed under an additional path — through a bind mount, for instance — is evaluated against whatever rules match *that* path; AppArmor provides `alias` rules precisely so a profile can declare two paths equivalent. The mirror-image cost of SELinux's model is that labels can be wrong: data moved rather than copied keeps its old type, and getting a service working can mean relabelling rather than editing rules. **Granularity of the escape hatch.** AppArmor profiles are individually in enforce or complain mode — `aa-complain /etc/apparmor.d/usr.sbin.nginx` puts exactly one program into log-only mode, and `aa-status` shows which profiles are in which mode. SELinux's permissive mode is global by default, though `semanage permissive -a <domain>` gives an equivalent per-domain escape. **Coverage beyond files.** SELinux labels object classes that have no pathname at all — TCP and UDP ports, sockets, IPC objects, capabilities — so a policy can express "this domain may bind only ports of this type". AppArmor has network rules and capability rules, but its file model is fundamentally about paths, and things without a path are covered differently. **Failure signature.** Both write to the audit subsystem, but the records look different. SELinux emits `avc: denied` with `scontext`/`tcontext`/`tclass`; AppArmor emits records containing `apparmor="DENIED"` with `operation=`, `profile=` and `name=` naming the path. Knowing which shape to grep for tells you immediately which system is confining the host. ```bash # Ubuntu-family: which profiles exist and what mode are they in? aa-status aa-complain /etc/apparmor.d/usr.sbin.nginx aa-enforce /etc/apparmor.d/usr.sbin.nginx # RHEL-family sestatus getenforce ``` ## Which one is on this machine? In practice a system runs one of them, not both: Debian and Ubuntu ship AppArmor enabled with profiles for a set of common services, while RHEL, Fedora and derivatives ship SELinux with the targeted policy. SUSE also uses AppArmor by default. When you land on an unfamiliar host, `sestatus` and `aa-status` answer the question in one command each, and a failure whose cause is invisible in the mode bits should send you to whichever of the two is active. ## The judgement an interviewer is listening for The weak answer is "SELinux is stricter and AppArmor is easier" — a slogan that survives no follow-up. The strong answer identifies the naming model as the root difference and derives the rest: why AppArmor profiles are readable but need every path enumerated, why SELinux confinement follows data across renames but drags relabelling along with it, and why an unprofiled binary is unconfined under AppArmor while SELinux has an opinion about everything on the system.