Targeted vs Minimum Targeted SELinux Policy for Web Hosting on AlmaLinux 9: Boolean Management Trade-offs
0 reputation · 25 Oct 2022, 03:24 UTC
0 reputation · 25 Oct 2022, 03:24 UTC
AlmaLinux 9 ships with the targeted SELinux policy enabled by default, which permits common network services while confining processes to their domains. The alternative minimum targeted policy reduces the set of active booleans, providing a stricter sandbox at the cost of requiring manual enablement for each service capability.
When moving workloads from CentOS 8 to AlmaLinux 9, SELinux booleans such as httpd_can_network_connect may revert to their default states. The targeted policy enables many of these booleans out of the box, while the minimum targeted policy leaves them disabled. Administrators using semanage boolean -m to set persistent values find that those settings do not automatically carry over if the policy type is changed between targeted and minimum targeted; a policy reload is required and existing boolean values are not migrated.
Third‑party web applications often depend on specific booleans being active. Under the minimum targeted policy, those booleans are off by default, potentially causing service failures unless pre‑configured. The targeted policy reduces this risk but expands the attack surface by enabling a broader set of permissions.
Which policy choice minimizes ongoing boolean maintenance for a fleet of web servers that must support both standard HTTP/HTTPS services and custom applications requiring network connectivity, while ensuring boolean persistence survives policy reloads and minor version upgrades?
33275 reputation · 25 Oct 2022, 12:05 UTC
Keep the default targeted policy on AlmaLinux 9. For a fleet that must run standard HTTP/HTTPS plus custom applications needing outbound network access, targeted minimizes ongoing boolean work: the booleans those workloads depend on are already enabled, and changes made with semanage boolean -m are stored per policy type, so they survive semodule -R reloads and ordinary minor package upgrades. The minimum targeted policy does not reduce maintenance — it moves the whole burden onto you, and it does not share your boolean store.
Well-established across RHEL-family 9 systems:
/etc/selinux/<policytype>/modules/active/booleans.local. That path is keyed to the active policy type, so targeted and minimum keep separate files.semodule -R) does not clear that file; the values are re-applied when policy loads.SELINUXTYPE= in /etc/selinux/config is a policy type change. It requires a relabel and does not carry boolean values across; they must be reapplied.httpd_can_network_connect are on by default; under minimum they are off, and a denied capability tends to surface as an AVC denial rather than a clear application error.Marked for review: the exact number of booleans enabled by default in each policy varies by release and by installed policy modules. Treat any specific count as approximate and confirm it on a representative host instead of trusting a number from a blog post.
sestatus | grep 'Loaded policy name'getsebool -a | grep httpd and semanage boolean -l -C (shows only locally modified booleans).semanage boolean -m --on httpd_can_network_connect.cat /etc/selinux/targeted/modules/active/booleans.local — the file may not exist until the first change.semodule -R, then getsebool httpd_can_network_connect; it should still read on.dnf update selinux-policy-targeted, repeat steps 1 and 5, and check ausearch -m avc -ts recent after deploying a custom app.| Factor | targeted | minimum targeted |
|---|---|---|
| Default boolean coverage for httpd network use | Broad; common booleans already on | Narrow; most must be enabled manually |
| Boolean store | /etc/selinux/targeted/... | /etc/selinux/minimum/... |
| Survives reload / minor upgrade | Yes, within the same policy type | Yes, within the same policy type |
| Survives a policy type switch | No | No |
| Fleet maintenance | Lower; defaults cover the common case | Higher; every capability is your responsibility |
| Attack surface | Broader set of allowed transitions | Narrower, but also omits whole policy modules |
The durable answer is not "pick the policy with more booleans on" but "declare the booleans you need." Manage them with a configuration management module — for example Ansible's seboolean with persistent: yes — so every node converges to the same state regardless of what the policy package ships. That removes the upgrade-time surprise where a rebuilt policy module changes a default, and it turns a future policy type change into one auditable edit rather than a fleet-wide manual pass.
If your environment has an external mandate — a compliance baseline, a hardening profile, or a customer contract — requiring the minimum policy regardless of operational cost, the recommendation flips: use minimum targeted, but pair it with a relabel plan, a declarative boolean manifest, and AVC monitoring from day one. Whether such a mandate exists is the one detail worth confirming before you standardize.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.