Day 2 is where Blastwall stops being a one-time CVE response and becomes an automation posture program. Operators decide what privileged automation should normally be allowed to do, encode that decision as SELinux policy source, test it against real automation, and promote the verified boundary like any other governed artifact.
The important boundary is ownership. AAP does not author SELinux policy. IdM does not author SELinux policy. Blastwall policy comes from the policy source operators maintain, build, test, package, deploy, verify, and then expose back to AAP as suitability state.
Where The Policy Comes From
The policy starts in policy/. The base blastwall.te module defines the automation SELinux user, role, and domain using the RHEL targeted policy model. The standalone CIL deny files subtract high-risk surfaces from that domain, such as AF_ALG, BPF, packet sockets, user namespace creation, io_uring, and direct policy self-protection.
That means the policy is not generated by Controller and it is not invented by IdM. The source of authority is the versioned SELinux policy artifact installed on the managed host. IdM records which identities and hosts are in scope, eigenstate.ipa translates that state into inventory facts, and AAP decides whether the host is suitable before the job runs.
| Layer | What It Contributes | What It Does Not Do |
|---|---|---|
| RHEL targeted policy | The standard SELinux policy foundation and ordinary RHEL domain model. | Know which automation identity should be hardened for this fleet. |
| Blastwall base policy | The named automation subject: blastwall_u, blastwall_r, and blastwall_t. | Decide every future deny scope by itself. |
| Blastwall CIL deny scopes | Explicit subtraction of risky or low-value surfaces from the automation domain. | Replace testing against real automation behavior. |
| Content pipeline | Versioned RPM build, promotion, rollback, and audit trail. | Prove the policy is correct without host-local verification. |
Baseline Disposition
A baseline disposition is the current answer to a narrow question: what should this class of privileged automation normally be able to do on a managed host? The answer should be specific to an automation population, not a universal claim about every process on the system.
The starting point is not a blank policy. Operators begin with the RHEL targeted policy substrate, the current Blastwall domain, and the automation they already run. Then they prune away surfaces that have high exploit value and low expected operational value for that automation path.
| Signal | Operator Question | Disposition Result |
|---|---|---|
| Known exploit pressure | Does this surface appear in current CVE or exploit-chain work? | Candidate deny scope. |
| Automation corpus | Do normal jobs actually need this capability? | Keep, deny, or split the automation identity. |
| Targeted policy grants | Is this permission inherited because it is generally useful, or because this automation needs it? | Prune broad grants when the automation path does not need them. |
| Verification output | Can the deny scope be probed safely and recorded clearly? | Promote only after proof and marker state exist. |
Use Automation As The Test Case
The most useful test corpus is the automation already running in the environment. Replay normal jobs in staging under blastwall_t, collect denials, and classify each finding before changing production posture.
A denial is not automatically a bug. It can mean the policy is too tight, the job is doing work that belongs in a different automation identity, or the policy correctly blocked behavior the job never should have needed.
| Observation | Interpretation | Next Action |
|---|---|---|
| Normal job fails on expected file, package, or service work. | The baseline is too narrow for this automation class. | Add a targeted allow or split the workflow into a more specific domain. |
| Job tries to create BPF, packet sockets, user namespaces, or io_uring. | The job is crossing into a high-risk surface with little expected automation value. | Keep the deny scope and investigate why the job wanted that surface. |
| Only one job needs a broad capability. | The shared automation identity may be too broad. | Consider a separate identity, host group, or policy domain for that workflow. |
| Probe output and audit logs agree. | The policy is enforceable and explainable. | Promote the artifact and write verified marker state. |
How A New Scope Enters The Baseline
A new scope should move through the same path every time. The decision starts as an exploit signal or posture decision, becomes policy source, becomes a build artifact, gets tested locally, becomes host-marker state, and finally becomes an AAP preflight condition.
| Stage | Policy Shape | Evidence Shape |
|---|---|---|
| Source | A CIL deny scope with a matching neverallow guard and a place in DENY_POLICIES. | The policy source says exactly what is being removed from blastwall_t. |
| Probe | A safe test that exercises the surface without exploiting a vulnerability. | BLOCKED, FAIL, or SKIP output that an operator can read. |
| Verification | A managed-host check that confirms the session is in blastwall_t and the denial applies there. | Command output and audit evidence agree. |
| Marker | A verified host claim such as blastwall_policy_userns=denied. | AAP inventory can distinguish current hosts from stale hosts. |
| Promotion | A versioned policy RPM in the normal content path. | The baseline is reviewable, reversible, and tied to a specific policy version. |
Optional SELinux object classes need special care. The current io_uring scope is wrapped in a CIL optional block so older kernels can ignore an unknown class while newer kernels still enforce it. The marker state must reflect what the host can actually enforce.
When A New CVE Lands
A new CVE should not immediately become a permanent Blastwall rule. It should become a triage question: is this surface reachable from the automation domain, does normal automation need it, and can the denial be verified safely?
| Question | Emergency Answer | Posture Answer |
|---|---|---|
| Can the automation identity reach the vulnerable surface? | Deny quickly in staging and prove the probe fails. | Decide whether the surface should ever be available to this automation class. |
| Will normal jobs break? | Run the current automation corpus against the candidate policy. | Split identities or domains when one workflow needs a risky capability. |
| Can AAP tell which hosts are safe? | Publish marker state only after local verification. | Make the deny scope part of the baseline preflight for sensitive jobs. |
| What happens after patching? | Keep the mitigation until the fleet state is proven. | Retire only when the capability is worth restoring for automation. |
The Day 2 Loop
The operating loop is deliberately boring: decide, encode, build, test, promote, verify, mark, and gate. That loop is what turns a clever deny rule into something an enterprise automation team can live with.
automation behavior + exploit signal
-> baseline disposition
-> SELinux policy source
-> policy RPM
-> staging replay and safe probes
-> host-local verification
-> IdM-visible marker
-> AAP preflight selectionThe strongest Blastwall posture is not the largest deny list. It is the smallest set of capabilities that still lets the automation do its intended work, with evidence that the boundary is current before a high-value job runs.