Configuring SELinux booleans for custom applications

SELinux on RHEL-based distributions enforces mandatory access control that often blocks custom services from binding to ports, writing to directories, or communicating over the network. Rather than disabling the framework entirely, administrators can flip specific runtime toggles called booleans to grant narrowly defined permissions. Getting booleans right is the difference between a hardened server and one that quietly runs in permissive mode.

A boolean is a runtime flag that turns a chunk of policy logic on or off without recompiling the policy package. Each one maps to a behaviour, such as allowing Apache scripts to send mail or letting a database daemon access user home directories. Knowing which booleans to flip, how to make them survive a reboot, and when to write a custom policy module is the practical skill this guide covers.

Understanding SELinux boolean logic

Every boolean lives inside the active policy module and exposes a yes-or-no value that the kernel checks whenever an application requests a permission. RHEL 9 ships with thousands of booleans, each tied to a precise use case described in the policy documentation. Reading the short help text tells administrators exactly which behaviour the flag controls.

Because booleans are evaluated at runtime, changes do not require reloading the SELinux policy or rebooting the host. That makes them useful when troubleshooting from a Sydney data centre or a Melbourne secondary site at midnight without scheduling downtime. A flipped flag either grants or denies the targeted action immediately, and /var/log/audit/audit.log confirms whether the change resolved the AVC denial.

Listing available booleans for your service

The getsebool and semanage boolean commands give a complete view of every flag in the current policy. Running semanage boolean -l prints a full table with descriptions, current state, and the policy module owning each flag. Piping through grep narrows the search to a particular daemon, such as httpd, postgres, or nfs.

For administrators managing a small fleet from a Perth office, listing the booleans tied to Apache before configuring virtual hosts on RHEL 9 saves significant troubleshooting time later. The output also shows the persistent default, which may differ from the active runtime value after a manual override. Understanding that distinction prevents confusion when a change appears to vanish after a reboot.

Identifying which booleans a custom app needs

When audit logs show an AVC denial for a custom binary, ausearch and audit2why translate the raw denial into human-readable advice. The output often names a specific boolean and recommends flipping it to allow the requested behaviour, rather than authoring a brand-new policy module. Following the suggestion is usually the safest path because the boolean has already been reviewed upstream.

Teams running bespoke monitoring agents out of Darwin frequently encounter booleans such as nagios_run_sudo_commands or collectd_tcp_network_connect that closely match their application's needs. Each candidate should be cross-checked against the application's actual behaviour, since granting sudo execution to a daemon that only needs to ping a remote endpoint weakens the host unnecessarily.

Enabling booleans with setsebool commands

The setsebool command flips a flag at runtime, and the change takes effect for the current session. A command like setsebool -P httpd_can_network_connect_db on enables database connections from the web server without a restart. The -P flag is what makes the change survive a reboot, though applying it briefly reloads the policy.

For environments operating under the Australian Privacy Principles and the Notifiable Data Breaches scheme, keeping SELinux enforcement active is part of demonstrating reasonable security safeguards. A boolean-driven approach lets teams open narrow exceptions while still meeting the protective obligations expected by the Office of the Australian Information Commissioner. It also satisfies the Essential Eight maturity requirements that many federal-adjacent agencies reference.

Making boolean changes persistent across reboots

Without the -P flag, setsebool changes revert at the next policy reload or system restart. Using -P writes the new value to the policy store on disk, ensuring the boolean comes back in the configured state every time the host boots. Persistent changes are visible immediately in semanage boolean -l and survive package updates that pull in newer policy versions.

A useful habit on multi-tenant hosts is to keep a record of every persistent boolean change in a configuration management playbook. Ansible, Puppet, or Salt can reapply the booleans after a clean reinstall, which is common when provisioning fresh nodes in Australian cloud regions. Documenting the rationale behind each flip also helps auditors trace why a particular exception exists during an IRAP-aligned assessment.

Creating custom policy modules for unique applications

When no existing boolean fits, the audit2allow utility generates a policy module from the AVC denials observed in audit logs. The module is compiled with checkmodule and semodule_package, then installed with semodule -i. Custom modules live alongside the stock policy and can be versioned in a Git repository alongside the application they protect.

A payments microservice deployed from a Sydney office might need access to a non-standard credential directory that no upstream boolean covers. Writing a minimal module that allows only read access to that single path preserves the principle of least privilege far better than disabling enforcement. Testing in a staging environment catches unintended permissions before the module reaches production.

Aligning boolean choices with Australian compliance

Hosting teams operating under the Privacy Act 1988 benefit from treating booleans as a documented part of the change-management process. Every boolean change should land in a ticketing system alongside the audit log entry that justified it. This creates a clear paper trail that satisfies both internal review and any regulator request.

Reviewing boolean exceptions ahead of an IRAP-style assessment is a healthy habit that pays off during audits. Booleans that have been enabled for years can be re-evaluated against the current application footprint, with stale flags turned off to shrink the attack surface. This periodic review supports evidence-gathering for the Essential Eight reporting required by the Australian Cyber Security Centre.

The takeaway for administrators is to keep SELinux in enforcing mode throughout the work, never treat booleans as a permanent workaround without a ticket, and persist every change with -P so a reboot does not undo the configuration. A boolean-tuned system running in enforcing mode delivers the narrow access custom applications need while preserving the layered defence that Australian compliance frameworks expect.