gprocunier/blastwall

GitHub: gprocunier/blastwall

一个利用 SELinux 受限用户域结合 FreeIPA/IdM 身份映射来约束特权自动化身份的概念验证,旨在为自动化会话建立默认拒绝的漏洞利用防火墙。

Stars: 0 | Forks: 0

# blastwall `blastwall` 是一个概念验证,旨在展示如何将 SELinux 用户限制用作特权自动化的漏洞利用防火墙。 这源自我在 [`privileged-automation-security`](https://gprocunier.github.io/privileged-automation-security/) 中提出的论点: 我不希望自动化继承与无限制人工操作者相同的假设,然后运行得更快。我希望自动化从一开始就受到约束。我希望脱离这种约束的行为是狭窄的、深思熟虑的且可见的。 第一个具体目标是 Copy Fail 漏洞利用路径。该项目受 Anthony Green 的 [`block-copyfail`](https://github.com/atgreen/block-copyfail) 概念验证启发。Anthony 的项目使用 BPF LSM 仅为 `authencesn` 阻止 `AF_ALG` 绑定。当缓解措施需要内核参数精度时,这是正确的形式。 Blastwall 提出了一个不同的问题。如果漏洞利用路径应该为特权自动化身份被阻止,我能否使其成为 RHEL 操作员已经期望理解的相同 SELinux、IdM、AAP 和内容交付模型的一部分?SELinux 无法检查 `authencesn` 算法字符串,因此这个概念验证阻止了映射自动化会话的更广泛攻击面:`blastwall_u` 域被完全拒绝 `alg_socket` 访问。 ## 为什么现在这很重要 发现新漏洞利用面的速度正在加快。Agentic AI 工具现在可以执行自主漏洞研究:代码审计、模糊测试、二进制分析和漏洞利用链构建。这些工具正在压缩从“漏洞存在”到“漏洞被武器化”之间的时间。过去需要专业研究团队花费数月时间的工作,现在可能在几天或几小时内浮出水面。 这改变了自动化的风险计算。每一个不受限制运行的自动化身份都是一个长期存在的邀请:当下一个内核 0-day 漏洞出现时,该身份已经具备了访问权限、速度和 reach,可以在补丁可用之前在整个集群中进行横向移动。采用广泛特权自动化而不加限制的组织正在构建一条高速公路。高速、高权限、低阻力,攻击者只需一个漏洞就能上路。 问题不在于是否会出现新的内核漏洞。而在于你的自动化身份是否已经受到足够的限制,使得漏洞的爆炸半径在你甚至不知道 CVE 编号之前就已受到界限约束。 Blastwall 就是围绕这一假设设计的:首先进行限制,默认拒绝自动化的广泛漏洞利用面,并使限制生命周期足够快,以便在威胁出现时能比内核补丁在集群中移动得更快地添加新的拒绝范围。 一份涵盖范围、信任边界、对手能力和具体攻击路径的正式威胁模型位于 [`THREAT-MODEL.md`](THREAT-MODEL.md)。 ## Calabi 演示 [`docs/demo.html`](docs/demo.html) 中的 GitHub Pages 演示是在 [`Calabi`](https://gprocunier.github.io/calabi/) 中录制的,这是我的实验室项目,用于将真实的断开连接的 OpenShift 和支持服务环境折叠到受控的 nested-KVM 系统中。在 Blastwall 中,Calabi 并不是必需的平台。我使用它作为验证实验室,因为它为证明提供了真实的 IdM 服务器、堡垒机、镜像仓库、Kerberos 流和受管端点,而不是模拟拓扑。 演示从 `bastion-01` 展示了概念验证:IdM 创建并证明 `svc-ansible-runner`,`eigenstate.ipa` 验证读取端门控,直接 GSSAPI SSH 探测落在 `blastwall_u:blastwall_r:blastwall_t:s0`,目标审计日志显示拒绝了 AF_ALG、BPF、packet_socket 和 userns 活动,最后的自我保护步骤证明 SELinux 阻止了通过 sudo 扩展的 `semodule` 突破。 ## 论点 我不认为 FreeIPA 应该编写 SELinux 策略。我认为 FreeIPA 应该将命名身份映射到端点上已经存在的 SELinux 用户和角色。我也不认为 AAP 应该在 playbook 运行到一半时才发现目标主机未处于正确的限制状态。 该模型分为三个部分: 1. 每个受管 RHEL 主机上的本地策略定义了 `blastwall_u`、`blastwall_r` 以及受限自动化域 `blastwall_root_local_t`。 2. FreeIPA/IdM 通过链接 HBAC 的 SELinux 用户映射,将 AAP 自动化身份映射到 `blastwall_u`。 3. AAP 在运行作业之前使用 [`eigenstate.ipa`](https://gprocunier.github.io/eigenstate-ipa/) 来选择符合条件的主机,并在 SELinux 映射、HBAC、sudo 或可选主机策略标记与预期不符时实行快速失败。 重点不是取代内核补丁。重点是让特权自动化落在一个狭窄的域中,在真正的修复程序仍在集群中部署的同时,可以在此快速阻止已知的漏洞利用面。 ## 灵感:block-copyfail `block-copyfail` 是这项工作的参考点,因为它展示了缓解措施的内核原生形式: - 挂钩相关的 LSM 决策点; - 检查包含算法名称的 syscall 参数; - 仅拒绝存在漏洞的 `authencesn` AF_ALG 绑定; - 放过不相关的 AF_ALG 用户。 这种精确性是 BPF LSM 的优势所在。Blastwall 并不在逐参数过滤上与之竞争。它借鉴了相同的实用经验,即应在漏洞利用到达脆弱的内核路径之前将其阻止,然后将控制边界移入自动化的信任模型中。 ![Copy Fail 精度工具与 Blastwall 自动化边界对比](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/88f87126dc001937.svg) ## 为什么我会构建它 我构建它是因为后勤保障很重要。 在 RHEL 自动化环境中,版本化的 SELinux 策略 RPM 通常比一组新的 eBPF 探针更容易进行暂存、推广、审计和回滚。这并不能使 SELinux 更精确。它使缓解措施能够适应 RHEL 操作中已经存在的机制。 如果可以通过拒绝自动化身份的广泛攻击面来缓解漏洞利用,这就是我想要的工作流: ![Blastwall 策略推出和库存反馈流程](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/54024fcf56001938.svg) 该路径在操作上是常规的: - RPM 版本控制为缓解措施提供了具体的构件名称。 - Satellite 可以暂存、推广、固定、报告和回滚该软件包。 - AAP 可以使用常规的 `dnf` 工作流安装该软件包。 - IdM 可以暴露哪些身份和主机在范围内。 - [`eigenstate.ipa`](https://gprocunier.github.io/eigenstate-ipa/) 可以在作业开始前让 AAP 感知 SELinux 映射、HBAC 访问权限、sudo 策略和可选的主机覆盖标记。 - 审计和变更控制可以更容易地分析 `blastwall-selinux-0.4.0-1`,而不是动态附加的探针。 权衡在于精确性。BPF LSM 可以检查内核挂钩参数并阻止一种确切的形态,例如 `socket_bind` 中的 `authencesn`。Blastwall 为特定的主体(映射到 `blastwall_u` 的特权自动化)阻止了更广泛的 SELinux 表面。 这对于自动化通常是可以接受的。许多 AAP 作业不应该需要 `AF_ALG`、BPF、原始数据包套接字或用户命名空间创建。为自动化身份阻止这些表面正是其意义的一部分。 简而言之: ``` BPF LSM is the precision tool. Blastwall is the identity, policy, and delivery model. ``` ## 这为 AAP 和 IdM 增加了什么 重要的问题不仅在于“这个漏洞利用能否被阻止?”。还在于: - 哪些自动化身份被允许在此主机上运行; - 这些身份是否落入受限的 SELinux 用户中; - sudo 是否在逃逸限制的情况下获取 root 权限; - AAP 能否在运行前判断哪些主机具有所需的缓解措施; - 策略覆盖是否可以通过 IdM 可见的主机状态进行版本化、推出和审计。 这就是 [`eigenstate.ipa`](https://gprocunier.github.io/eigenstate-ipa/)、AAP 和 IdM 组合发挥作用的地方。IdM 是身份、主机范围、HBAC、sudo、 SELinux 用户映射和可选主机策略标记的事实来源。AAP 在执行之前使用该事实。 SELinux 在自动化会话建立后提供主机本地强制执行。 ![IdM、eigenstate.ipa、AAP、SSH 和 SELinux 强制执行流程](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/cb467a8b40001939.svg) 主机不仅仅是打过补丁或未打过补丁的。对于给定的作业,它是合适还是不合适取决于当前的 IdM 状态和本地策略覆盖。 ## 覆盖范围扩展模型 将 Blastwall 视为一个小型策略产品,而不是一次性的规则。如果另一个高价值的漏洞利用面应该在集群打补丁之前为自动化被阻止,工作流如下: 1. 用 SELinux 可以强制执行的语言定义新的漏洞利用面。 2. 向 Blastwall 策略源添加新的策略范围。 3. 生成并审查更新后的策略模块/RPM。 4. 提升 Blastwall 策略版本。 5. 将策略推出到符合条件的主机。 6. 使用新版本和覆盖范围声明更新 IdM 主机标记。 7. 让 AAP 清单和预检仅偏向具有所需覆盖范围的主机。 这可以防止紧急缓解措施变成未跟踪的本地状态。每条新规则都有版本、声明的范围和清单可见的推出状态。 ### 自我保护范围 策略自我保护现在是 Blastwall 的基础范围。它不是像 `alg_socket` 或 `bpf` 那样针对特定漏洞的缓解措施。它保护的是“墙”本身。 当前的自我保护 CIL 拒绝 `blastwall_t` 执行 SELinux 策略管理入口点(例如 `semodule`、`semanage`、`setsebool` 和 `load_policy`),拒绝使用 SELinux `security` 类权限(例如 `load_policy`、`setenforce` 和 `setbool`),并拒绝在常见的目标策略类型下写入本地 SELinux 策略存储。我故意没有拒绝进程上下文设置器(如 `setexec` 或 `setkeycreate`);sudo 需要它们来遵循 `role=blastwall_r` 和 `type=blastwall_t` 选项,而不会回退到无限制的上下文。 Calabi 验证 playbook 临时将 `/usr/sbin/semodule` 添加到 Blastwall sudo 命令组,证明自动化用户可以看到扩展的 sudo 范围,然后尝试移除一个拒绝模块。预期结果不是 sudo 拒绝。预期结果是 SELinux 拒绝从 `blastwall_t` 对 `semanage_exec_t` 的执行,并且之后 Blastwall 模块仍然安装。 ![从漏洞利用面到 AAP 预检的覆盖范围扩展生命周期](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/4076d0f59f001939.svg) ## 架构流程 ![从 AAP 作业到 SELinux 拒绝的 Blastwall 架构流程](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/d7993be22a001940.svg) ## 仓库布局 - `policy/` - SELinux reference-policy 模块和登录上下文模板。 - `idm/` - 用于组、HBAC、sudo 和用户映射的 IdM 对象创建示例。 - `inventory/` - 用于 AAP 的 [`eigenstate.ipa.idm`](https://gprocunier.github.io/eigenstate-ipa/) 清单源。 - `playbooks/` - AAP/controller 预检、策略部署和主机检查。 - `tests/` - 用于验证拒绝的安全 AF_ALG、BPF、packet_socket 和 userns 探测。 - `poc-calabi/` - 用于在观看演示后重放验证路径的 Calabi 实验室练习。 ## IdM 关系模型 ![IdM 组、主机组、HBAC、SELinux 映射和 sudo 关系模型](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/9b67e58ebb001941.svg) ## 要求 受管 RHEL 主机需要: - SELinux 处于强制模式。 - SELinux 用户空间 3.6 或更高版本以支持 CIL `deny` 规则。 - `selinux-policy-devel` - `checkpolicy` - `policycoreutils-python-utils` - `make` 运行预检的 AAP 执行环境需要: - [`eigenstate.ipa`](https://gprocunier.github.io/eigenstate-ipa/) - `python3-ipalib` - `python3-ipaclient` - `krb5-workstation` - 已挂载的 IdM keytab 和 CA 证书 使用以下命令安装 Ansible 集合依赖项: ``` ansible-galaxy collection install -r requirements.yml ``` ## 快速演示流程 在每个受管主机上,安装本地 SELinux 策略和登录上下文: ``` sudo make -C policy install sudo install -D -m 0644 \ policy/contexts/blastwall_u \ /etc/selinux/targeted/contexts/users/blastwall_u sudo semanage user -a -R blastwall_r -r s0 blastwall_u ``` 如果 `blastwall_u` 已经存在,请改为修改它: ``` sudo semanage user -m -R blastwall_r -r s0 blastwall_u ``` 在 IdM 中,创建 [`idm/bootstrap-blastwall.yml`](idm/bootstrap-blastwall.yml) 中描述的自动化组、受管主机组、HBAC 规则、sudo 规则和 SELinux 用户映射。 [`poc-calabi/`](poc-calabi/) 中的 Calabi 实验室练习展示了使用 Ansible 的完整对象创建路径。 在 AAP 中,从以下位置同步清单: ``` inventory/blastwall-idm.yml ``` 在任何变更作业之前,运行: ``` playbooks/preflight.yml ``` 然后运行受管主机验证: ``` playbooks/verify-managed-host.yml ``` ## 运行时强制执行流程 ![映射自动化会话的运行时强制执行序列](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/214c9b5a79001942.svg) ## 可选的主机适用性标记 [`eigenstate.ipa.idm`](https://gprocunier.github.io/eigenstate-ipa/) 可以将 IdM 主机属性导出到清单 hostvars 中。 此概念验证使用 `idm_description` 作为简单的载体,因为它已可从正常的主机记录中使用。 策略部署 playbook 为每个经过验证的覆盖范围声明写入一个标记: ``` blastwall_policy_rpm=blastwall-selinux-0.4.0-1 blastwall_policy_state=active blastwall_policy_alg_socket=denied blastwall_policy_bpf=denied blastwall_policy_selfprotect=denied blastwall_policy_packet_socket=denied blastwall_policy_userns=denied ``` 当覆盖范围扩展时,仅添加已实际强制执行并在本地验证过的表面的标记。避免重载单个布尔值;AAP 应该能够请求作业所需的确切策略版本和拒绝范围。 然后,清单组将符合条件的主机分为: - `blastwall_policy_current` - `blastwall_policy_stale` 这些标记是补充性的。它们帮助 AAP 在多个主机符合 HBAC 条件时选择最佳候选者。它们不取代实时的 SELinux、HBAC、sudo 和运行时验证。 ![从本地证明到 AAP 目标决策的主机适用性标记流程](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/7891764935001943.svg) ## 具有多重覆盖的候选选择 当两台主机都可访问并映射到 `blastwall_u` 时,AAP 应优先选择具有最新策略和作业所需覆盖范围的主机。只需要 Copy Fail 缓解措施的作业可以接受 `alg_socket=denied`;响应较新漏洞利用的作业可以同时要求较旧和较新的标记。 ![具有多重覆盖标记的 AAP 候选选择](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/a5227b32c7001944.svg) 这些标记本身不是证明。推出工作流应仅在本地验证确认策略已安装且预期的拒绝可观察到之后才更新标记。 ## 类型别名说明 reference-policy 用户模板创建具体的域 `blastwall_t`。 该策略还定义了 `blastwall_root_local_t` 作为类型别名,以便公共概念验证上下文名称描述 root-local 自动化意图。某些 SELinux 工具会将别名规范化回 `blastwall_t`;只要 SELinux 用户和角色仍然是 `blastwall_u` 和 `blastwall_r`,验证 playbook 就会接受这两个名称。 ## 重要限制 SELinux 可以阻止受限自动化域的广泛对象类访问。 它无法匹配内核挂钩参数,例如 `struct sockaddr_alg` 中的 `authencesn`。当前策略拒绝演示过的自动化表面:用于 Copy Fail 的 `alg_socket`、`bpf`、`packet_socket` 和 `userns_create`。它还包含一个自我保护范围,阻止 `blastwall_t` 运行 SELinux 策略管理工具或写入本地 SELinux 策略存储。如果要求在保留被阻止类的其他用途的同时实现参数级别的精度,请继续使用像 Anthony Green 的 `block-copyfail` 这样的 eBPF LSM 缓解措施。 ![SELinux 广泛类拒绝与 BPF LSM 参数精度对比](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/3cc327433b001945.svg) 此概念验证使用 CIL `deny` 模块,因为当前的发行版策略可能会通过继承的用户域属性授予套接字权限。deny 规则从 `blastwall_t` 减去 `alg_socket` 访问;配对的 `neverallow` 防止未来的策略更改静默恢复该权限。 ## 何时选择哪个 当我需要最窄的运行时缓解措施并希望保留不相关的 AF_ALG 使用时,我会使用 `block-copyfail` 风格的 BPF LSM。它是围绕脆弱的内核参数塑造的,这正是它有用的原因。 当缓解措施应该与自动化身份、主机范围以及 RHEL 环境的实际操作方式绑定时,我会使用 Blastwall。优势不在于更精细的内核检查。优势在于相同的控制平面可以回答: - 谁可以自动化此主机; - 他们获得哪个 SELinux 用户; - 他们继承什么 sudo 策略; - 主机策略声称覆盖什么漏洞利用面; - AAP 是否应该运行、跳过或修复该主机。 这两种方法可以很好地组合。BPF LSM 在内核挂钩处为我提供了精度。Blastwall 为我提供了一个身份范围的自动化边界和一个 AAP 在接触主机之前就可以使用的推出记录。
标签:0day挖掘, 0-day防护, AAP, AF_ALG, Agentic AI, AI自动化安全, alg_socket, Ansible自动化平台, BPF LSM, Copy Fail, CSV导出, exploit firewall, GitHub Advanced Security, IdM, Linux安全模块, LSM, PE 加载器, PoC, RHEL, SELinux, XXE攻击, 内核安全, 安全加固, 安全概念验证, 安全策略, 安全防护, 提示词设计, 暴力破解, 权限约束, 横向移动防御, 漏洞利用防火墙, 特权自动化, 用户隔离, 算法套接字, 系统提示词, 红帽企业版Linux, 身份管理, 逆向工具