blastwall

The 2-Minute Version

Privileged automation is a governed identity path, not just a remote shell. Blastwall gives that path a central record, a preflight gate, a host-local SELinux domain, and visible evidence when the selected host is suitable.

That matters because emergency exploit mitigation can become automation posture: source, RPM, rollout, verification, host marker, AAP inventory sync, and preflight selection.

Start Here

Pick the page by the job you need the documentation to do. Each path has one next page.

The Problem

Privileged automation often gets the same broad local shape as an operator, then runs faster, across more hosts, with less human friction. If that automation lands unconfined, a mistake or exploit starts from a position that is difficult to defend.

Think of the automation identity like a service truck with master keys. The useful control is not only the key. It is the dispatch record, the driver identity, the approved job site, and the worksite limits before the truck rolls into every building.

Copy Fail makes this practical. Exploit-specific tools such as block-copyfail can block a vulnerable AF_ALG shape with BPF LSM precision. Blastwall asks a different scoped question: should privileged automation have that broad surface while the fleet waits for kernel fixes?

Why This Matters Now

Copy Fail and Dirty Frag are examples of a larger pressure pattern: exploit research, fuzzing, and vulnerability triage are moving faster. Broad privileged automation turns that speed into fleet risk because one useful kernel path can be exercised across many hosts before a patch is ready.

Organizations that adopt broad privileged automation without confinement are building a superhighway: high speed, high privilege, low friction, and an attacker only needs one exploit to get on the road.

From Emergency Mitigation To Automation Posture

The first Blastwall use case is response: a risky kernel path appears before the fleet is fully patched, so the automation account gets a named SELinux boundary and the workflow proves that the right hosts have the right deny scopes before jobs run.

The more durable use case is proactive. Once privileged automation has a named boundary, operators can treat that boundary like a governed artifact: build it, test it, promote it, watch what breaks, and tighten it through CI/CD. The question changes from "can we block this CVE path?" to "what should privileged automation ever be allowed to do?"

User namespace creation is the clearest example in the current proof. It is often useful in exploit chains and rarely useful for this automation identity path, so Blastwall denies it before the next userns-adjacent CVE becomes urgent.

Dirty Frag shows the reactive side of the same model. Within a day of public disclosure, the policy gained xfrm and RxRPC deny scopes, a safe verification probe, and AAP-visible evidence that the automation identity cannot reach those entry points.

Architecture Mini-Map

Blastwall works by keeping responsibilities explicit. AAP is the gate and evidence surface, IdM is the authority and record source, eigenstate.ipa is the state translator, and SELinux is the host-local enforcement boundary.

For the full explanation, read Architecture. For the object-by-object identity model, read IdM Control Model. For the host-local enforcement model, read SELinux Control Model. For the operational policy lifecycle, read Day 2 Operations.

Proof Paths

The AAP demo is the path I would show first: it is the operator-facing proof with Controller objects, workflow launch, credential smoke, preflight, and managed-host verification. The Ansible demo is the bootstrap proof: it shows the IdM shape, policy rollout, direct probes, audit evidence, and self-protection mechanics without relying on AAP.

The OpenShift/SPO path is a separate workload proof. It does not force pods into the RHEL login-domain context; it uses SPO and SCC to run selected workloads in standard blastwall or explicit-exception blastwall-nested classes.

Both recordings were made in Calabi, a nested-KVM lab with a real IdM server, bastion host, mirror registry, Kerberos flow, and managed endpoint. Calabi is the validation environment, not a Blastwall runtime requirement.

What This Does Not Claim

• It does not replace kernel fixes, exploit-specific BPF LSM controls, seccomp, gVisor, Falco, Tetragon, EDR, or container isolation.
• It does not prove that host markers are trustworthy by themselves. Markers are useful only after verification writes them and preflight refreshes or rejects stale state.
• It does not claim that SELinux can inspect the same hook arguments as BPF LSM. The tradeoff is broader denial for a specific automation identity path.

How It Scales

The policy should not remain emergency local state. A useful deny scope, whether it starts from a live CVE or a proactive posture decision, has an artifact name, a rollout state, a local proof, an IdM-visible marker, and an AAP preflight condition.

Repository Layout