blastwall

blastwall is a proof of concept for privileged automation security on RHEL. The idea is simple: automation should not arrive on managed hosts with the same unconfined local shape as a human operator. Red Hat Identity Management (IdM) should decide who may run, Ansible Automation Platform (AAP) should act on that state, and SELinux should confine the session when it reaches the host.

The first concrete target is the copy.fail exploit path. Anthony Green's block-copyfail shows the precise BPF LSM answer for that vulnerability. Blastwall takes a different angle: if a risky kernel surface should be unavailable to privileged automation identities, can that mitigation move through the same SELinux, IdM, AAP, and RHEL content delivery model operators already understand?

This follows from the argument I made in privileged-automation-security: automation moves too quickly and too broadly to inherit every assumption we make about an interactive privileged shell.

Start Here

The GitHub Pages site is the best entry point: gprocunier.github.io/blastwall.

Need	Start With
Understand the 2-minute model	Architecture
Watch the operator-facing proof	AAP Demo
Inspect the bootstrap and host-local mechanics	Ansible Demo
Reproduce the AAP recording	AAP Lab
Reproduce the Ansible-only proof	Ansible Lab
Understand the IdM relationship model	IdM Control Model
Understand the SELinux boundary	SELinux Control Model
Compare Blastwall with adjacent tools	Comparison
Review assumptions and attack paths	Threat Model
Look up terms and acronyms	Glossary
Look up exact objects and expected outputs	Reference

What It Proves

Blastwall joins four responsibilities that are usually discussed separately:

Part	Role
SELinux	Enforces the host-local automation boundary.
IdM	Records identity, host scope, HBAC, sudo, SELinux user maps, and host markers.
eigenstate.ipa	Reads IdM state into inventory-visible facts.
AAP	Launches workflows, runs preflight checks, selects suitable hosts, and records evidence.

The recorded demos show that an automation identity can land in blastwall_u:blastwall_r:blastwall_t:s0, use sudo without escaping that domain, and hit denied AF_ALG, BPF, packet_socket, userns, and io_uring probes. The AAP path also shows Controller-visible credential smoke, IdM inventory sync, preflight selection, workflow node status, and managed-host verification output.

Repository Map

Path	Purpose
policy/	SELinux reference-policy module and CIL deny rule.
idm/	IdM group, hostgroup, HBAC, sudo, and SELinux user-map examples.
inventory/	eigenstate.ipa.idm inventory source for AAP.
playbooks/	Preflight, deployment, credential smoke, and verification playbooks.
aap/	Controller configuration-as-code for the AAP workflow.
execution-environment/	AAP execution environment definition.
poc-calabi/	Calabi lab overlay used to record and replay the proof.
docs/	GitHub Pages documentation and recordings.

Requirements

• RHEL or compatible hosts with SELinux enforcing.
• IdM/FreeIPA for identity, HBAC, sudo, SELinux user mapping, and host markers.
• AAP/Automation Controller for the Controller-based workflow.
• eigenstate.ipa for inventory-aware IdM state.
• Ansible collection dependencies from collections/requirements.yml.

Install collection dependencies with:

ansible-galaxy collection install -r collections/requirements.yml

Documentation Shape

The docs intentionally separate reader needs:

• architecture.html explains the control chain and authority boundaries.
• demo pages explain what the recordings prove.
• lab pages guide replay from a prepared environment.
• comparison and threat-model pages review scope fit, assumptions, attack paths, and residual risk.
• glossary and reference pages define terms, exact objects, and expected outputs.

That split keeps the landing page and README from becoming a maze of setup steps, architecture debate, and term definitions.