What is SELinux?
SELinux, short for Security-Enhanced Linux, is a security module in the Linux kernel that adds mandatory access control on top of ordinary file permissions. The NSA developed it and released it as open source in 2000, and it has been part of the mainline kernel since 2003. It is enabled and enforcing by default on Red Hat Enterprise Linux and related distributions such as Fedora, CentOS Stream, Rocky Linux and AlmaLinux, and Android has run it in enforcing mode since Android 5.0.
Standard Linux permissions are discretionary: a file's owner decides who may read or write it, and root can override everything. Under SELinux, a system-wide policy decides what each process may touch, and that policy binds processes running as root as well. If an attacker exploits a web server, the hijacked process is still held to what the policy lets the web server do.
How SELinux works: labels and type enforcement
SELinux attaches a security context to every process, file, directory, port and socket, written as user:role:type:level. The part that matters most is the type. Policy rules state which process types, called domains, may perform which actions on which object types. A database running in the mysqld_t domain can use files labeled mysqld_db_t, but it cannot read a file labeled user_home_t unless a rule says so. Anything no rule permits is refused and logged. This model is called type enforcement. The default targeted policy confines network-facing daemons and leaves most interactive user sessions unconfined; a multilevel security (MLS) policy adds sensitivity levels for classified environments.
ls -Z shows file labels and ps -eZ shows process domains. Denials are written to /var/log/audit/audit.log as AVC (access vector cache) messages.
The three SELinux modes
- Enforcing: violations are blocked and logged. This is the production setting.
- Permissive: nothing is blocked, but every would-be denial is logged. It has a legitimate use for a short time while profiling a new application.
- Disabled: SELinux is off, and files created while it is off get no labels, so turning it back on requires relabeling the file system.
getenforce and sestatus report the current mode. setenforce 0 drops a running system to permissive until the next reboot, while the persistent setting lives in /etc/selinux/config. Turning SELinux off completely takes a boot-time change and a reboot.
Example: a service on a nonstandard port
An administrator configures Apache to listen on TCP 3131 for an internal tool. The service refuses to start, although nothing else is using the port. The audit log shows an AVC denial for the name_bind permission: policy lets the httpd_t domain bind only to ports labeled http_port_t, and 3131 is not one of them. The fix is to label the port, not to weaken SELinux:
semanage port -a -t http_port_t -p tcp 3131
Other fixes follow the same pattern. Web content kept in an unusual directory gets a permanent file-context rule with semanage fcontext, applied with restorecon. An optional behavior, such as letting the web server reach a remote database, is switched on with a boolean, for example setsebool -P httpd_can_network_connect_db on. Running setenforce 0 would also clear the error, but only by removing confinement from every service on the host.
SELinux vs. AppArmor and file permissions
- File permissions: discretionary and owner-controlled, and root bypasses them.
- SELinux: mandatory, label-based policy enforced by the kernel across files, ports, processes and more.
- AppArmor: also mandatory access control in the kernel, but its profiles confine programs by file path instead of labels. Ubuntu and Debian use it by default.
SELinux on the CompTIA Security+ exam
SELinux appears in SY0-801 objective 4.1 as an operating system security control used in hardening, and it is on the exam's acronym list. It also serves as the standard example of mandatory access control among the access control models in objective 4.5. Wording such as confine a compromised service even when it runs as root, labels on files and processes or AVC denied in the audit log points to SELinux. When an application breaks and one answer says to disable SELinux or set it to permissive, that answer is almost always the distractor; the better choice fixes the label, the port type or the boolean. Another distractor is chmod 777, which loosens discretionary permissions and does nothing about an SELinux denial.