SELinux

SELinux enforcing/permissive modes, contexts, audit2allow, chcon, semanage, and restorecon.

Overview

SELinux (Security-Enhanced Linux) is a Mandatory Access Control (MAC) system built into the Linux kernel. Unlike Discretionary Access Control (DAC — the traditional Unix permission model), SELinux enforces policy rules that even the root user cannot override. Every process and file is labeled with a security context, and the policy defines which process labels may access which file labels.

MAC vs DAC

DAC (traditional Unix permissions): the file owner decides who can access the file. Root can bypass all DAC restrictions. If a process is compromised, it inherits all the permissions of the user running it.

MAC (SELinux): the security policy — written by administrators and defined by the OS vendor — controls access. Even root cannot access a resource if the SELinux policy denies it. A compromised web server running as root cannot read /etc/shadow if the policy prohibits httpd_t from accessing shadow_t files.

Three Modes

Enforcing — policy is enforced. Denials block the operation and are logged to /var/log/audit/audit.log.
Permissive — policy is not enforced but denials are logged. Use for debugging.
Disabled — SELinux is off. Requires a reboot to re-enable (inode relabeling required).

Context Format

Every file and process has a label in the format: user:role:type:level

user — SELinux user identity (e.g., system_u, unconfined_u)
role — SELinux role (e.g., object_r for files, system_r for daemons)
type — the primary enforcement dimension (e.g., httpd_sys_content_t)
level — MLS/MCS sensitivity level (e.g., s0)

The type field is what policy rules typically reference.

Key concepts

Security context: Four-part label user:role:type:level on every file and process. The type field drives most policy rules. View with ls -Z (files) or ps -Z (processes).
AVC denial: Access Vector Cache denial — the kernel's record that SELinux blocked an operation. Found in /var/log/audit/audit.log as type=AVC lines. Contains subject context, object context, and the operation denied.
chcon: Changes a file's SELinux context temporarily (reset by relabeling or restorecon). chcon -t httpd_sys_content_t /data/site/ — use only for testing; use semanage fcontext for persistent changes.
semanage fcontext: Records a persistent context rule in the policy database. semanage fcontext -a -t httpd_sys_content_t '/srv/mysite(/.*)?' then restorecon -Rv /srv/mysite to apply.
restorecon: Resets file contexts to the policy default. restorecon -Rv /var/www/html — -R for recursive, -v for verbose. Always run after semanage fcontext.
audit2allow: Reads AVC denials from audit.log and generates a policy module allowing those operations. audit2allow -M mypolicy < /var/log/audit/audit.log then semodule -i mypolicy.pp.
setsebool: Sets named SELinux booleans that toggle policy behaviors. setsebool -P httpd_can_network_connect on allows Apache to make outbound network connections. -P makes it persistent across reboots.

When to use it

A service fails to start and logs show "Permission denied" — check audit.log for AVC denials before disabling SELinux
A web server cannot read its docroot after moving files — restorecon -Rv /var/www/html to restore contexts
Adding a new custom port for a service — semanage port -a -t http_port_t -p tcp 8443
Granting a custom application access to a resource — audit2allow to convert AVC denial to a policy module
Checking if SELinux is the cause of a problem — set to permissive temporarily, reproduce the issue, then read denials

Interview questions

Nginx fails to serve files from /srv/mysite. You see "Permission denied" in the error log. Walk through the SELinux diagnosis and fix.
What is audit2allow and when should you use it vs writing a proper policy?