Linux
View all Worklets
LinuxLinux

Linux - System Preferences - Configure and Enable SELinux

Harden Linux endpoints by setting SELinux to enforcing mode with the targeted policy across RHEL, CentOS, and Fedora fleets

Worklet Details

What the SELinux enforcing-mode Worklet does

This Automox Worklet™ places Security-Enhanced Linux (SELinux) into enforcing mode with the targeted policy type on every Linux endpoint under management. The Worklet first verifies that /etc/selinux/config exists, then reads the SELINUX and SELINUXTYPE values currently written to the file. Endpoints without an SELinux configuration file are skipped with exit code 0 so the policy is safe to run against a mixed Linux fleet.

SELinux provides mandatory access control (MAC) layered on top of standard Linux discretionary permissions. Enforcing mode actively denies any access that violates policy, while the targeted policy confines network-facing daemons (sshd, httpd, named, smbd, postgresql) without breaking the user-space applications most workstations need. The Worklet preserves the mls policy type when an endpoint is already configured for it, so high-assurance hosts are not silently downgraded.

Beyond the configuration file, the Worklet inspects the boot loader. If /boot/grub exists the legacy GRUB menu.lst is checked; if /boot/grub2 exists the GRUB2 grub.cfg is checked. Any selinux=0 or enforcing=0 kernel argument is stripped from /etc/default/grub and the boot configuration is regenerated with update-grub or grub2-mkconfig. A final re-evaluation pass confirms all three controls (boot, mode, type) before the Worklet exits.

Why enforce SELinux on every Linux endpoint

SELinux separates a contained service compromise from a full host takeover. When sshd, httpd, or a database daemon is exploited on a permissive-mode endpoint, the attacker inherits the daemon's discretionary permissions and pivots from there. With enforcing mode and the targeted policy active, the same exploit lands inside a confined domain (httpd_t, sshd_t, postgresql_t) that cannot read /etc/shadow, write outside its labeled directories, or load arbitrary kernel modules. The CIS Distribution Independent Linux Benchmark v2.0.0 explicitly requires SELINUX=enforcing and SELINUXTYPE=targeted, which is the configuration the Worklet writes.

SELinux drift compounds quietly. A developer adds selinux=0 to /etc/default/grub to debug a packaging issue and forgets to revert it, a golden image ships with SELINUX=permissive because the build pipeline never tightened it, a vendor installer rewrites /etc/selinux/config during a product install. Apply this Worklet through the Linux hardening policy that covers RHEL, CentOS, Rocky, and Alma so SELINUX=enforcing and SELINUXTYPE=targeted land in /etc/selinux/config and the boot loader is rebuilt without disable arguments. A recurring evaluation catches the drift before it shows up in an audit finding or a post-incident review. The control maps to CIS RHEL Benchmark 1.6.1 and NIST 800-53 AC-3.

How SELinux enforcement works

  1. Evaluation phase: The Worklet checks for /etc/selinux/config and exits 0 if the file is missing, marking the endpoint as not eligible. It extracts the SELINUX and SELINUXTYPE values with grep and awk, then identifies the boot loader by probing /boot/grub and /boot/grub2. The kernel line in /boot/grub/menu.lst or /boot/grub2/grub.cfg is inspected to confirm SELinux has not been disabled at boot. The endpoint is flagged for remediation when SELINUX is not enforcing, when SELINUXTYPE is neither targeted nor mls, or when the boot loader has been tampered with, and evaluation exits 1 to schedule remediation.

  2. Remediation phase: On GRUB2 endpoints the remediation script strips selinux=0 and enforcing=0 from /etc/default/grub with sed, then rebuilds the boot configuration using update-grub or grub2-mkconfig. On legacy GRUB endpoints the script removes any line containing selinux=0 or enforcing=0 from menu.lst. It rewrites /etc/selinux/config so SELINUX=enforcing and SELINUXTYPE=targeted, leaving an existing mls policy intact. A final pass through evaluate_SELinux_boot, evaluate_SELinux_is_enforcing, and evaluate_SELinux_type confirms the changes, and the Worklet exits 0 on success or 1 with a stderr message if any control still reports fail.

SELinux hardening requirements

  • Linux endpoint with SELinux installed (RHEL, CentOS, Rocky, Alma, Fedora, or any distribution shipping the selinux-policy-targeted package)

  • /etc/selinux/config present on disk; endpoints without this file are skipped automatically

  • GRUB or GRUB2 boot loader (the Worklet auto-detects which is in use)

  • Root or sudo privileges for the Automox agent so sed can rewrite /etc/selinux/config and /etc/default/grub

  • Minimum Automox agent version 1.42.22; the Worklet is FixNow compatible for on-demand runs

  • Reboot after first remediation; an endpoint transitioning from disabled to enforcing must relabel the filesystem, which only happens during the next boot

Expected SELinux state after remediation

After the remediation pass, /etc/selinux/config reads SELINUX=enforcing and SELINUXTYPE=targeted (or SELINUXTYPE=mls if the endpoint was already on mls). The /etc/default/grub kernel command line no longer carries selinux=0 or enforcing=0, and /boot/grub2/grub.cfg has been regenerated to reflect the cleaned arguments. Running getenforce after the next reboot returns Enforcing, and sestatus reports SELinux status as enabled with the policy type currently loaded. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again, because all three evaluation checks pass on the first read.

Validate by running sestatus and confirming Current mode: enforcing, Loaded policy name: targeted, and Mode from config file: enforcing. Run ausearch -m AVC --start recent on a SIEM-collected host to confirm no avc: denied events were generated against expected workloads, then check /var/log/audit/audit.log for the policy version that loaded at boot. For audit evidence, capture the contents of /etc/selinux/config and the output of getenforce alongside the Automox policy run identifier. The configuration remains active across reboots and kernel upgrades; it is only undone if an administrator edits /etc/selinux/config or appends a disable argument to GRUB, at which point the next evaluation reads the disabled value or the bad kernel argument and remediation rewrites the file and regenerates the boot configuration.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets