Blastwall is built around one claim: privileged automation should not arrive on managed RHEL hosts with the same unconfined local shape as a human operator. Red Hat Identity Management (IdM) defines who may arrive, Ansible Automation Platform (AAP) acts on that state, and SELinux confines the session after login.
Problem Statement
Privileged automation is valuable because it moves quickly across many hosts. That same reach becomes a security problem when the automation identity lands as a broad unconfined local subject. A single useful kernel path, unsafe local tool, or overbroad sudo rule can become fleet-scale exposure.
Blastwall narrows the problem to privileged automation confinement. It does not replace patching, exploit-specific BPF LSM controls, seccomp profiles, EDR, container isolation, or runtime detection. It asks whether a managed RHEL fleet can make automation arrive in a governed identity shape and then confine that shape on the host.
Control Chain
The chain is deliberately explicit: IdM records the identity and access model, eigenstate.ipa translates that model into inventory facts, AAP gates and records execution, SSH and SSSD apply the login path, pam_selinux applies the SELinux login mapping, SELinux denies the configured surfaces, and audit output gives the reviewer host-local evidence.
Responsibility Table
| Component | Responsibility | Not Its Job | Evidence |
|---|---|---|---|
| IdM | Records automation identity, host groups, HBAC, sudo, SELinux user maps, and host markers. | Authoring SELinux policy or proving kernel denials. | IdM records and inventory facts shown in the demos. |
eigenstate.ipa | Reads IdM state and exposes it as Ansible inventory facts. | Making enforcement decisions on the host. | Current and stale host groups in AAP preflight. |
| AAP | Syncs code and inventory, gates execution, launches workflow nodes, and records stdout. | Acting as the SELinux enforcement engine. | Controller objects, workflow graph, node status, and job output. |
| SSSD and PAM | Apply central identity, access, and SELinux login mapping during SSH login. | Replacing AAP preflight or policy packaging. | The runtime context becomes blastwall_u:blastwall_r:blastwall_t:s0. |
| SELinux | Enforces host-local denials for the confined automation domain. | Knowing fleet suitability or Controller workflow intent. | Denied AF_ALG, BPF, packet_socket, userns, io_uring, and policy self-protection probes. |
| Audit log | Records host-local denial evidence. | Serving as the preflight decision source. | Target-host audit entries for denied operations. |
Enforcement Boundary
AAP and IdM shape the arrival conditions, but the kernel denial happens on the managed host. The important runtime evidence is the mapped process context: blastwall_u:blastwall_r:blastwall_t:s0. In SELinux terms, blastwall_u is the SELinux user, blastwall_r is the role, and blastwall_t is the process type/domain.
Sudo can still reach UID 0 for delegated work. The proof checks that sudo does not move the automation process out of blastwall_t, and that the confined domain cannot remove the deny modules even after a temporary sudo rule exposes /usr/sbin/semodule.
Lifecycle Of A Deny Scope
A useful emergency mitigation needs more than a local policy edit. It needs a source change, a versioned artifact, rollout, local verification, a marker that AAP can read, and preflight logic that refuses stale or unsuitable hosts.
-
1
Define the deny scope
- Identify low-value automation surface
- Update Blastwall SELinux policy
-
2
Publish an artifact
- Build policy RPM
- Stage through the content pipeline
-
3
Verify locally
- Install or refresh policy
- Run safe denial probes
-
4
Feed preflight
- Write verified host marker
- Sync IdM-backed inventory
- Select only current hosts
Evidence Loop
The demos prove different parts of the same loop. The AAP Demo is the operator-facing proof: Controller objects, credential smoke, inventory sync, preflight, workflow launch, node status, and job stdout. The Ansible Demo is the bootstrap proof: IdM object creation, policy rollout, direct probes, audit evidence, and self-protection.
The host marker is useful only after verification writes it. The marker helps AAP avoid stale hosts, but it is not the enforcement boundary and it is not proof by itself.
Why Each Part Matters
| Part | Why It Matters |
|---|---|
| SELinux | It enforces the host-local domain after the automation identity arrives and after sudo reaches UID 0. |
| IdM | It gives the fleet a central record for identity, access, mapping, sudo, host membership, and verified coverage markers. |
eigenstate.ipa | It turns IdM records into inventory state that Ansible and AAP can query before runtime work begins. |
| AAP | It makes the gate and evidence visible to operators through workflow nodes, stdout, launch identity, and Controller history. |
Limits And Assumptions
- Blastwall reduces blast radius for a defined automation identity path. It does not fix the kernel vulnerability.
- SELinux denies the broader surface shown in policy. It does not inspect the same hook arguments as exploit-specific BPF LSM controls.
- AAP is a gate and evidence surface. The managed host still performs enforcement.
- IdM markers can be stale or spoofed by sufficiently privileged actors. Verification must refresh or reject marker state before high-value workflows depend on it.
- The proof is a lab proof of concept. Production use would need hardening around credentials, marker integrity, rollout scope, emergency rollback, and multi-host scale.