SELinux

SELinux — Security-Enhanced Linux — is the mandatory-access-control layer the NSA open-sourced into the kernel: born of the agency's FLUX/FLASK research prototypes, released under the GPL in December 2000, and merged mainline during the 2.5–2.6 development series (~2003). Where Unix permissions ask "who owns this file and what do the bits say," SELinux asks "what is this process's context, and does policy grant this exact operation" — a web server labeled httpd_t can't read /etc/shadow even if a bug gives it root, because no rule in the policy says it may.^[1]

Labels, not paths

Every subject (process) and object (file, socket) carries a security context — user:role:type:level, displayed by ls -Z and ps -Z. Policy compiles type-enforcement rules (allow httpd_t httpd_sys_content_t:file read;) into a binary database the kernel consults on every access; denials land in the audit log as AVC messages. Distributions ship policies — targeted (protect daemons, leave users loose) is the Fedora/RHEL default, strict and mls exist for high-assurance work. The daily tools: sestatus, getenforce/setenforce, semanage, restorecon, audit2allow.^[2]

The honest reputation

SELinux earned a reputation for hostility — the classic admin fix of "setenforce 0" is famous enough to be a joke — but modern targeted policy plus audit2allow makes it tractable, and Android ships it enforcing on every phone: billions of devices run MAC without knowing it. The rival is AppArmor (Debian/Ubuntu/SUSE's path-based answer — simpler, weaker); the security chapter's MAC section compares both.^[3]

See also

• Linux Security — the MAC/least-privilege chapter
• Inside a Linux System — the kernel layer it hooks
• Processes — the subjects it labels
• Linux · Nftables · LUKS