SELinux Booleans Are Policy Switches That Need an Owner
SELinux booleans let an administrator change part of a loaded policy without writing a new policy module. They are convenient during troubleshooting: a service that cannot reach a resource may work after one boolean is enabled. That convenience also makes booleans a common source of silent policy drift.
The Red Hat SELinux guide describes booleans as runtime policy changes that can be listed with semanage boolean -l. A change made with setsebool -P is intended to persist across reboots. The exact meaning and risk of a boolean depend on the policy module and the service it affects. There is no universal "safe" boolean, and a name that sounds narrow can enable a broader class of access.
Separate diagnosis from policy change
When a service is denied, the first useful evidence is the SELinux denial and the object label involved. Enabling a boolean before collecting that evidence removes the signal. The service may start, but the team no longer knows whether the policy was wrong, the file label was wrong, or the application was doing something it should not do.
Use audit records, ausearch, sealert, and the service documentation to identify the intended policy path. Check the file context first. A misplaced label is often corrected with restorecon or a properly managed context rule, not a global boolean. If a boolean is genuinely required, record why the packaged policy did not cover the deployment and which access it unlocks.
Runtime value versus local customization
Booleans can be viewed as current runtime state and as locally customized policy state. A reboot or policy reload can change the effective value if the customization was not made persistent. The command setsebool -P is the documented way to make a change persist, but persistence does not make the change correct. A persistent exception can outlive the incident that inspired it.
Review local boolean changes with the same controls as a firewall exception:
- owner and business reason;
- affected domain and service;
- access enabled;
- test that proves the service needs it;
- expiry or review date;
- rollback instruction.
The review should distinguish a temporary diagnostic toggle from a production baseline. A host that was repaired manually during an outage should be reconciled with configuration management rather than left in an undocumented state.
Booleans do not replace type enforcement
SELinux is built around labels, domains, type transitions, and policy rules. A boolean changes the behavior of conditional policy. It does not guarantee that a service stays in its intended domain, that a file has the correct type, or that an unconfined process is contained.
Check the process domain after enabling a boolean. A service started from an unexpected path may run in a different domain than the packaged unit. A container runtime may use a different policy path. The boolean may appear to solve the symptom while the process is still operating with the wrong label or an overly broad entry point.
Operational verification
A useful verification sequence is:
- Record the current boolean state and the relevant process and file labels.
- Reproduce the denial with a controlled request.
- Apply the narrowest documented correction.
- Confirm the service works and the denial is resolved for the intended reason.
- Test that an unrelated resource remains denied.
- Restart or reboot the host and confirm the intended state persists.
- Store the evidence with the configuration change.
The fifth step catches a common mistake: enabling broad access and declaring success because the original request now works. The policy may have become so permissive that other paths also work. Test one negative case.
The review rule
A boolean is a policy decision, not a support checkbox. It needs a named owner, a documented scope, and an exit path. The same rule applies whether the setting is part of a large enterprise policy or a single host under incident pressure. SELinux is most useful when its decisions remain visible and explainable.
Top comments (0)