gprocunier/privileged-automation-security
GitHub: gprocunier/privileged-automation-security
该项目提出了一种基于 SELinux 和 FreeIPA 的特权自动化安全模型，通过拆分 Root 权限并结合事件驱动响应来限制自动化账户的横向移动能力。
Stars: 0 | Forks: 0
# SELinux 限制的自动化、FreeIPA 映射与 Root 重组
## 论点
我认为自动化的默认信任模型是错误的。
在 RHEL 上，许多已交付的软件已经受益于针对性的 SELinux 限制，但登录用户默认情况下仍然不受限制，通常映射为 `unconfined_u`。我认为该模型在编排方面无法很好地扩展。对于需要在 shell 中即兴发挥、检查和恢复的人员来说，这是合理的。对于自动化来说，这就不太合理了，因为自动化的常规模式是从广泛的信任开始，然后通过 `sudo`、SSH 和现有凭据进行转向。
我不希望自动化继承与人类操作员相同的假设，然后以更快的速度行动。我希望自动化从受限状态开始，并且我希望任何脱离该限制的移动都是狭窄、刻意且可见的。
设计很简单：
- 端点承载实际的 SELinux 策略
- FreeIPA 将命名身份映射到这些 SELinux 用户和角色
- SSSD 和 `pam_selinux` 在登录时应用该映射
- 该角色可以包含本地 root 等效权限，而不会自动包含网络转向权限
- 绕过限制边界应该足够嘈杂，以触发响应
我认为这是现代自动化的一个更好的模型，而不是将编排视为一个手速更快的未受限制的人。
## FreeIPA 实际提供的内容
我不认为 FreeIPA 是编写 SELinux 策略的地方。我认为它是将身份映射到端点上已有策略的正确位置。
这种区别很重要。FreeIPA 和 Red Hat IdM 文档将 SELinux 用户映射描述为一种关联以下内容的方式：
- 一个 SELinux 用户
- 一个 IdM 用户或组
- 一个主机或主机组
- 或一个提供匹配的用户端和主机端的 HBAC 链接范围
这是一个清晰的控制平面边界。FreeIPA 回答了“在这个主机上，该身份应该获得哪个 SELinux 用户？”这个问题。它不回答“这个主机的 SELinux 策略是什么？”第二个问题属于策略管道和端点。
SSSD 在客户端评估映射，`pam_selinux` 在选定的上下文中启动会话。具体性和配置的顺序很重要。直接用户映射优先于组映射。直接主机范围优先于更广泛的主机组范围。如果没有更具体的匹配，顺序和默认值决定发生什么。
这就足够集中化了。FreeIPA 不需要成为策略引擎。我需要它成为身份在大规模下落入正确限制的地方。
```
flowchart LR
A["Policy pipeline
defines SELinux users, roles, domains, transitions"] --> B["Managed endpoint
policy installed locally"] C["FreeIPA
maps identity to SELinux user by host scope"] --> D["SSSD + pam_selinux
evaluates map and starts session"] B --> D D --> E["Confined session"] ``` ## 默认模型在何处失效 默认模型假设从广泛信任的用户上下文开始并依赖程序来防止这种信任传播得太远是可以接受的。 在现代自动化中，这种假设很快就会失效。 如果自动化身份被攻破，问题不仅仅是它可能错误地执行一项本地任务。问题在于该身份通常继承了整个操作员模型： - 广泛的 shell 访问权限 - `sudo` - 出站网络访问 - SSH 客户端行为 - 通过节点进行转向 - 访问本地信任材料 这种环境权限太多了。 Red Hat 自己的文档已经指出了这一差距。一方面，针对性的 SELinux 正在为服务做实际工作。另一方面，交互式用户会话通常是不受限制的。我认为自动化一直处于那条线的错误一侧。 ## 为什么现在这更重要 这也是对一类不同攻击者的回应，而许多操作模型都是围绕另一类攻击者构建的。 Check Point Research 关于 VoidLink 的报告是这种转变的一个有用标志。他们将其描述为一个专为现代基础设施设计的云优先 Linux 恶意软件框架，明确了解主要云环境、Kubernetes 和 Docker，以及针对云和版本控制上下文的凭据收集。他们还描述了一个广泛的基于插件的框架、多个 C2 通道和强大的操作安全功能。他们的报告并没有字面上说“这是一个编排攻击框架”，但我认为从云原生、容器感知的设计以及对软件工程师和基础设施相邻凭据的关注来看，这是一个合理的方向性推断。 重要的是这迫使假设发生了变化。如果攻击者正在为 Linux 基础设施构建云优先、模块化、快速发展的工具，那么我认为仅加强网络边缘并在其进入内部后信任编排是不够的。我需要假设自动化身份、编排路径和控制平面主机是攻击面的一部分。在那个世界里，减少转向权限并在限制内重组 root 不再看起来是学术性的，而是开始变得实用。 ## 我想要的模型 我想要一小部分组织定义的 SELinux 用户和域用于自动化。我希望通过策略管道将它们发送到端点。我希望 FreeIPA 将身份映射到它们。我希望基准角色是特定于功能的且狭窄的。 我宁愿使用像这样的小型分类法： - `ops_inventory_u` - `ops_backup_u` - `ops_patch_u` - `ops_deploy_u` - `ops_root_local_u` - `ops_root_networked_u` - `ops_breakglass_u` 我不希望每个工具都有一个 SELinux 用户。我想要几个反映功能和风险的角色。 我还希望主机范围很重要。部署身份不一定在构建主机、应用程序主机和堡垒主机上落入同一个 SELinux 用户。FreeIPA 已经为我提供了主机敏感的映射层。 ``` sequenceDiagram participant I as Named automation identity participant H as Target host participant S as SSSD + pam_selinux participant F as FreeIPA or SSSD cache participant P as Local SELinux policy I->>H: authenticate H->>S: start session S->>F: resolve SELinux map S->>P: select valid local role/domain S-->>I: launch confined session ``` ## Root 重组 我也不再把 `root` 视为一个单一的东西。我认为它是一个可以在 SELinux 策略下拆分并重新组装的包。 对我来说重要的不是抽象的 EUID 0。重要的是在该进程周围的 SELinux 域中实际存在哪些权限。Red Hat 的受限管理员模式足以表明 Unix 身份并不是全部故事。当会话执行类似 root 的工作时，SELinux 上下文仍然很重要。 我希望能够说自动化角色具有本地 root 等效权限，而不会自动说它具有： - 任意出站网络连接 - SSH 转向权限 - 访问节点上的每个密钥或代理套接字 - 一条将一次攻陷转变为机群移动的免费路径 这就是我关心的拆分。本地管理权限、网络发起、转向行为和篡改能力是单独授予的。 ``` flowchart TB R["Root-equivalent authority"] --> L["Local file and process control"] R --> S["Service management"] R --> P["Package and label operations"] R --> N["Outbound network initiation"] R --> X["SSH pivot behavior"] R --> K["Access to remote trust material"] subgraph A[What I would allow in ops_root_local_t] L S P end subgraph B[What I would grant separately or deny] N X K end ``` 我认为这很重要，因为如今太多的自动化假设如果某件事需要在机器上以 root 身份行动，那么它也可以从该机器上充当网络操作员。我不接受将其作为默认值。 ## 为什么我不围绕共享的直接 `root` 构建此模型 FreeIPA 映射 IdM 身份。字面意义上的共享本地 `root` 帐户并不完全适合该模型。我认为更清晰的模式是： - 作为命名自动化身份进行身份验证 - 通过 FreeIPA 将该身份映射到受限的 SELinux 用户 - 在需要时转换到 EUID 0，同时保留 SELinux 限制边界 这给了我想要的大部分内容：root 等效的本地权限，而无需放弃身份、归因或集中映射。 如果有人坚持到处进行直接的共享 `root` 登录，那么大多数有趣的控制都必须移回本地策略和本地登录处理。那时 FreeIPA 的故事就会变弱。 ## 为什么这对 Ansible 很重要 Ansible 使这种权衡变得显而易见。 我希望能够登录主机进行自动化，执行本地管理工作，并且仍然拒绝该会话成为通用跳点的能力。 在我设想的模型中，主机可以接受一个命名自动化身份，该身份最终以 EUID 0 运行任务，但该会话仍然会落入类似 `ops_root_local_u:ops_root_local_r:ops_root_local_t` 的状态。 这将允许任务执行我真正关心的本地事情： - 编写批准的配置 - 在策略允许的地方恢复或应用标签 - 重启批准的服务 - 执行批准的包工作 我不希望同一会话默认执行的操作是： - 打开任意出站 TCP 会话 - 通过 SSH 转到其他节点 - 通过主机中继作为跳点 - 改用本地信任材料进行与任务无关的移动 这就是我追求的爆炸半径缩减。 ## 密封策略和重启即绊网 仅靠 SELinux 无法提供密封的防篡改故事。 在标准 RHEL 系统上，`root` 仍然可以做一些在这里很重要的事情。它可以在运行时使用 `setenforce` 更改 SELinux 模式。它可以使用 `semodule` 安装或覆盖策略模块。它可以通过配置或内核参数（如 `enforcing=0` 或 `selinux=0`）在启动时削弱 SELinux。 我描述的模型依赖于更强的东西： - 运行时限制来自 SELinux 策略 - 防篡改价值来自将生产策略视为密封状态 - 绕过该密封应该需要更高摩擦的操作 - 绕过事件应该在主机外部可见 重启路径作为一个合理的绊网。如果削弱或绕过密封运行时策略的实际方法是跨越启动状态边界，那么攻击者必须用隐蔽性换取权力。如果事件在主机外部可见并且组织准备好对此做出反应，我可以接受这一点。 ``` flowchart TD A["Compromised automation identity
EUID 0 in confined domain"] --> B{"Desired action"} B -->|approved local work| C["Allowed inside policy"] B -->|network pivot or policy bypass| D["Denied by SELinux domain"] D --> E{"Can it quietly break the seal?"} E -->|no| F["Must weaken boot state or reboot"] F --> G["Off-host telemetry records the event"] E -->|yes| H["The design failed"] ``` 我不需要在这里进行完美的预防。我需要提高绕过的成本，并提高绕过的可见性。 ## 为什么事件驱动响应很重要 如果绊网想法止步于检测，我认为它是不完整的。如果密封破坏事件在主机外部可见，我希望系统的其余部分自动对其做出反应。这就是事件驱动 Ansible 的用武之地。Red Hat 的事件驱动 Ansible 模型是围绕规则手册、决策环境和控制器集成构建的，这些集成对传入事件做出反应并触发自动化作为响应。 我想要的是： - 重启事件 - 启动状态更改 - 发送的审计记录 - 其他关于策略削弱的主机外遥测 成为响应自动化的事件源。 可能的反应很简单： - 将主机从正常自动化清单中隔离 - 通过批准的网络控制工作流隔离主机 - 撤销或禁用与事件关联的身份 - 启动证据收集或取证保存 - 在主机再次受信任之前需要紧急恢复 ``` flowchart LR A["Managed host
reboot / SELinux state change / audit event"] --> B["Off-host telemetry
logging, SIEM, event stream"] B --> C["Event-Driven Ansible
rulebook activation"] C --> D{"Tripwire rule matches?"} D -->|yes| E["Launch response workflow"] D -->|no| F["Keep monitoring"] E --> G["Quarantine or isolate host"] E --> H["Disable identity or revoke access"] E --> I["Collect evidence or trigger remediation"] ``` 这将绊网从被动检测转变为主动遏制。 ## 防护栏 如果我试图实现这一点，我会在几件事上坚持立场。 - 我不会让自动化在没有审查的情况下静默回退到像 `unconfined_u` 这样的广泛默认值。 - 我不会发布仅在宽容模式下测试过的自定义策略。 - 我不会仅仅因为容易命名就为每个工具创建一个新的 SELinux 用户。 - 我不会允许每个自动化角色默认转换到 `sysadm_r:sysadm_t` 或任何等效角色。 - 我不会将紧急恢复路径视为正常管道。 - 除非主机外可见性和响应路径真正存在，否则我不会谈论密封。 ## 我将如何试点 我将分小步骤进行。 首先，我将在非生产主机类上使用类似 `ops_inventory_u` 的东西验证映射路径。然后，我将为一个应用程序层添加一个受限的具有写入权限的角色，如 `ops_deploy_u`。只有在那之后，我才会在真正需要本地 root 等效行为但不需要通过主机转向的工作流上试点 `ops_root_local_u`。 这个顺序对我来说很重要： - 证明身份到上下文的映射路径 - 证明仍然可以做有用工作的受限角色 - 然后证明没有网络蔓延的 root 重组 我会把紧急恢复和更广泛的联网 root 等效角色留到以后。 ## 我的结论 我不认为正确的问题是 SELinux 是否能使自动化完全安全。我认为正确的问题是它是否能迫使自动化进入一个更狭窄、更清晰的信任模型。 我认为它可以。FreeIPA 提供映射层。端点策略提供执行边界。SELinux 为我提供了一种将 root 拆分成块的方法，而不是将其视为完全信任状态。密封和主机外遥测使绕过可见。事件驱动 Ansible 为我提供了一种在该绊网触发时做出反应的方法。 这种组合感觉比我继承的模型更接近我想要的模型。 ## 来源 - FreeIPA，SELinux 用户映射模型和优先级：https://www.freeipa.org/page/SELinux_user_mapping - Red Hat，IdM SELinux 映射概念：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/identity_management_guide/mapping-selinux - Red Hat，IdM SELinux 顺序和默认行为：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/config-selinux - Red Hat，IdM 和 SELinux 登录流程与 SSSD 和 `pam_selinux`：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-managing_confined_services-identity_management - Red Hat，受限和未受限用户，包括 `user_u`、`staff_u` 和 `sysadm_u`：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/managing-confined-and-unconfined-users - Red Hat，SELinux 模式和使用 `setenforce` 的运行时状态更改：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/changing-selinux-states-and-modes_using-selinux - Red Hat，SELinux 模式、启动时更改以及内核参数（如 `enforcing=0` 和 `selinux=0`）：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/changing-selinux-states-and-modes - Red Hat，本地 SELinux 策略模块安装和使用 `semodule` 覆盖：https://docs.redhat.com/es/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/security-enhanced_linux-prioritizing_selinux_modules - Red Hat，受限用户角色和网络限制模式（如 `_r` 和 `xguest_r`）：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/managing-confined-and-unconfined-users_using-selinux - Red Hat Ansible Automation Platform，事件驱动 Ansible 控制器、规则手册激活、决策环境以及与自动化控制器的集成：https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.4/pdf/event-driven_ansible_controller_user_guide/red_hat_ansible_automation_platform-2.4-event-driven_ansible_controller_user_guide-en-us.pdf - Check Point Research，VoidLink 作为具有云和容器感知能力的云优先 Linux 恶意软件框架：https://research.checkpoint.com/2026/voidlink-the-cloud-native-malware-framework/
defines SELinux users, roles, domains, transitions"] --> B["Managed endpoint
policy installed locally"] C["FreeIPA
maps identity to SELinux user by host scope"] --> D["SSSD + pam_selinux
evaluates map and starts session"] B --> D D --> E["Confined session"] ``` ## 默认模型在何处失效 默认模型假设从广泛信任的用户上下文开始并依赖程序来防止这种信任传播得太远是可以接受的。 在现代自动化中，这种假设很快就会失效。 如果自动化身份被攻破，问题不仅仅是它可能错误地执行一项本地任务。问题在于该身份通常继承了整个操作员模型： - 广泛的 shell 访问权限 - `sudo` - 出站网络访问 - SSH 客户端行为 - 通过节点进行转向 - 访问本地信任材料 这种环境权限太多了。 Red Hat 自己的文档已经指出了这一差距。一方面，针对性的 SELinux 正在为服务做实际工作。另一方面，交互式用户会话通常是不受限制的。我认为自动化一直处于那条线的错误一侧。 ## 为什么现在这更重要 这也是对一类不同攻击者的回应，而许多操作模型都是围绕另一类攻击者构建的。 Check Point Research 关于 VoidLink 的报告是这种转变的一个有用标志。他们将其描述为一个专为现代基础设施设计的云优先 Linux 恶意软件框架，明确了解主要云环境、Kubernetes 和 Docker，以及针对云和版本控制上下文的凭据收集。他们还描述了一个广泛的基于插件的框架、多个 C2 通道和强大的操作安全功能。他们的报告并没有字面上说“这是一个编排攻击框架”，但我认为从云原生、容器感知的设计以及对软件工程师和基础设施相邻凭据的关注来看，这是一个合理的方向性推断。 重要的是这迫使假设发生了变化。如果攻击者正在为 Linux 基础设施构建云优先、模块化、快速发展的工具，那么我认为仅加强网络边缘并在其进入内部后信任编排是不够的。我需要假设自动化身份、编排路径和控制平面主机是攻击面的一部分。在那个世界里，减少转向权限并在限制内重组 root 不再看起来是学术性的，而是开始变得实用。 ## 我想要的模型 我想要一小部分组织定义的 SELinux 用户和域用于自动化。我希望通过策略管道将它们发送到端点。我希望 FreeIPA 将身份映射到它们。我希望基准角色是特定于功能的且狭窄的。 我宁愿使用像这样的小型分类法： - `ops_inventory_u` - `ops_backup_u` - `ops_patch_u` - `ops_deploy_u` - `ops_root_local_u` - `ops_root_networked_u` - `ops_breakglass_u` 我不希望每个工具都有一个 SELinux 用户。我想要几个反映功能和风险的角色。 我还希望主机范围很重要。部署身份不一定在构建主机、应用程序主机和堡垒主机上落入同一个 SELinux 用户。FreeIPA 已经为我提供了主机敏感的映射层。 ``` sequenceDiagram participant I as Named automation identity participant H as Target host participant S as SSSD + pam_selinux participant F as FreeIPA or SSSD cache participant P as Local SELinux policy I->>H: authenticate H->>S: start session S->>F: resolve SELinux map S->>P: select valid local role/domain S-->>I: launch confined session ``` ## Root 重组 我也不再把 `root` 视为一个单一的东西。我认为它是一个可以在 SELinux 策略下拆分并重新组装的包。 对我来说重要的不是抽象的 EUID 0。重要的是在该进程周围的 SELinux 域中实际存在哪些权限。Red Hat 的受限管理员模式足以表明 Unix 身份并不是全部故事。当会话执行类似 root 的工作时，SELinux 上下文仍然很重要。 我希望能够说自动化角色具有本地 root 等效权限，而不会自动说它具有： - 任意出站网络连接 - SSH 转向权限 - 访问节点上的每个密钥或代理套接字 - 一条将一次攻陷转变为机群移动的免费路径 这就是我关心的拆分。本地管理权限、网络发起、转向行为和篡改能力是单独授予的。 ``` flowchart TB R["Root-equivalent authority"] --> L["Local file and process control"] R --> S["Service management"] R --> P["Package and label operations"] R --> N["Outbound network initiation"] R --> X["SSH pivot behavior"] R --> K["Access to remote trust material"] subgraph A[What I would allow in ops_root_local_t] L S P end subgraph B[What I would grant separately or deny] N X K end ``` 我认为这很重要，因为如今太多的自动化假设如果某件事需要在机器上以 root 身份行动，那么它也可以从该机器上充当网络操作员。我不接受将其作为默认值。 ## 为什么我不围绕共享的直接 `root` 构建此模型 FreeIPA 映射 IdM 身份。字面意义上的共享本地 `root` 帐户并不完全适合该模型。我认为更清晰的模式是： - 作为命名自动化身份进行身份验证 - 通过 FreeIPA 将该身份映射到受限的 SELinux 用户 - 在需要时转换到 EUID 0，同时保留 SELinux 限制边界 这给了我想要的大部分内容：root 等效的本地权限，而无需放弃身份、归因或集中映射。 如果有人坚持到处进行直接的共享 `root` 登录，那么大多数有趣的控制都必须移回本地策略和本地登录处理。那时 FreeIPA 的故事就会变弱。 ## 为什么这对 Ansible 很重要 Ansible 使这种权衡变得显而易见。 我希望能够登录主机进行自动化，执行本地管理工作，并且仍然拒绝该会话成为通用跳点的能力。 在我设想的模型中，主机可以接受一个命名自动化身份，该身份最终以 EUID 0 运行任务，但该会话仍然会落入类似 `ops_root_local_u:ops_root_local_r:ops_root_local_t` 的状态。 这将允许任务执行我真正关心的本地事情： - 编写批准的配置 - 在策略允许的地方恢复或应用标签 - 重启批准的服务 - 执行批准的包工作 我不希望同一会话默认执行的操作是： - 打开任意出站 TCP 会话 - 通过 SSH 转到其他节点 - 通过主机中继作为跳点 - 改用本地信任材料进行与任务无关的移动 这就是我追求的爆炸半径缩减。 ## 密封策略和重启即绊网 仅靠 SELinux 无法提供密封的防篡改故事。 在标准 RHEL 系统上，`root` 仍然可以做一些在这里很重要的事情。它可以在运行时使用 `setenforce` 更改 SELinux 模式。它可以使用 `semodule` 安装或覆盖策略模块。它可以通过配置或内核参数（如 `enforcing=0` 或 `selinux=0`）在启动时削弱 SELinux。 我描述的模型依赖于更强的东西： - 运行时限制来自 SELinux 策略 - 防篡改价值来自将生产策略视为密封状态 - 绕过该密封应该需要更高摩擦的操作 - 绕过事件应该在主机外部可见 重启路径作为一个合理的绊网。如果削弱或绕过密封运行时策略的实际方法是跨越启动状态边界，那么攻击者必须用隐蔽性换取权力。如果事件在主机外部可见并且组织准备好对此做出反应，我可以接受这一点。 ``` flowchart TD A["Compromised automation identity
EUID 0 in confined domain"] --> B{"Desired action"} B -->|approved local work| C["Allowed inside policy"] B -->|network pivot or policy bypass| D["Denied by SELinux domain"] D --> E{"Can it quietly break the seal?"} E -->|no| F["Must weaken boot state or reboot"] F --> G["Off-host telemetry records the event"] E -->|yes| H["The design failed"] ``` 我不需要在这里进行完美的预防。我需要提高绕过的成本，并提高绕过的可见性。 ## 为什么事件驱动响应很重要 如果绊网想法止步于检测，我认为它是不完整的。如果密封破坏事件在主机外部可见，我希望系统的其余部分自动对其做出反应。这就是事件驱动 Ansible 的用武之地。Red Hat 的事件驱动 Ansible 模型是围绕规则手册、决策环境和控制器集成构建的，这些集成对传入事件做出反应并触发自动化作为响应。 我想要的是： - 重启事件 - 启动状态更改 - 发送的审计记录 - 其他关于策略削弱的主机外遥测 成为响应自动化的事件源。 可能的反应很简单： - 将主机从正常自动化清单中隔离 - 通过批准的网络控制工作流隔离主机 - 撤销或禁用与事件关联的身份 - 启动证据收集或取证保存 - 在主机再次受信任之前需要紧急恢复 ``` flowchart LR A["Managed host
reboot / SELinux state change / audit event"] --> B["Off-host telemetry
logging, SIEM, event stream"] B --> C["Event-Driven Ansible
rulebook activation"] C --> D{"Tripwire rule matches?"} D -->|yes| E["Launch response workflow"] D -->|no| F["Keep monitoring"] E --> G["Quarantine or isolate host"] E --> H["Disable identity or revoke access"] E --> I["Collect evidence or trigger remediation"] ``` 这将绊网从被动检测转变为主动遏制。 ## 防护栏 如果我试图实现这一点，我会在几件事上坚持立场。 - 我不会让自动化在没有审查的情况下静默回退到像 `unconfined_u` 这样的广泛默认值。 - 我不会发布仅在宽容模式下测试过的自定义策略。 - 我不会仅仅因为容易命名就为每个工具创建一个新的 SELinux 用户。 - 我不会允许每个自动化角色默认转换到 `sysadm_r:sysadm_t` 或任何等效角色。 - 我不会将紧急恢复路径视为正常管道。 - 除非主机外可见性和响应路径真正存在，否则我不会谈论密封。 ## 我将如何试点 我将分小步骤进行。 首先，我将在非生产主机类上使用类似 `ops_inventory_u` 的东西验证映射路径。然后，我将为一个应用程序层添加一个受限的具有写入权限的角色，如 `ops_deploy_u`。只有在那之后，我才会在真正需要本地 root 等效行为但不需要通过主机转向的工作流上试点 `ops_root_local_u`。 这个顺序对我来说很重要： - 证明身份到上下文的映射路径 - 证明仍然可以做有用工作的受限角色 - 然后证明没有网络蔓延的 root 重组 我会把紧急恢复和更广泛的联网 root 等效角色留到以后。 ## 我的结论 我不认为正确的问题是 SELinux 是否能使自动化完全安全。我认为正确的问题是它是否能迫使自动化进入一个更狭窄、更清晰的信任模型。 我认为它可以。FreeIPA 提供映射层。端点策略提供执行边界。SELinux 为我提供了一种将 root 拆分成块的方法，而不是将其视为完全信任状态。密封和主机外遥测使绕过可见。事件驱动 Ansible 为我提供了一种在该绊网触发时做出反应的方法。 这种组合感觉比我继承的模型更接近我想要的模型。 ## 来源 - FreeIPA，SELinux 用户映射模型和优先级：https://www.freeipa.org/page/SELinux_user_mapping - Red Hat，IdM SELinux 映射概念：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/identity_management_guide/mapping-selinux - Red Hat，IdM SELinux 顺序和默认行为：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/config-selinux - Red Hat，IdM 和 SELinux 登录流程与 SSSD 和 `pam_selinux`：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-managing_confined_services-identity_management - Red Hat，受限和未受限用户，包括 `user_u`、`staff_u` 和 `sysadm_u`：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/managing-confined-and-unconfined-users - Red Hat，SELinux 模式和使用 `setenforce` 的运行时状态更改：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/changing-selinux-states-and-modes_using-selinux - Red Hat，SELinux 模式、启动时更改以及内核参数（如 `enforcing=0` 和 `selinux=0`）：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/changing-selinux-states-and-modes - Red Hat，本地 SELinux 策略模块安装和使用 `semodule` 覆盖：https://docs.redhat.com/es/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/security-enhanced_linux-prioritizing_selinux_modules - Red Hat，受限用户角色和网络限制模式（如 `_r` 和 `xguest_r`）：https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/managing-confined-and-unconfined-users_using-selinux - Red Hat Ansible Automation Platform，事件驱动 Ansible 控制器、规则手册激活、决策环境以及与自动化控制器的集成：https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.4/pdf/event-driven_ansible_controller_user_guide/red_hat_ansible_automation_platform-2.4-event-driven_ansible_controller_user_guide-en-us.pdf - Check Point Research，VoidLink 作为具有云和容器感知能力的云优先 Linux 恶意软件框架：https://research.checkpoint.com/2026/voidlink-the-cloud-native-malware-framework/
标签：CSV导出, FreeIPA, GitHub Advanced Security, JSONLines, osquery, PAM, RBAC, Red Hat IdM, RHEL, SELinux, SSH, SSSD, Streamlit, sudo, Web报告查看器, 人工智能安全, 合规性, 后端开发, 子域名枚举, 安全加固, 安全策略, 提示词设计, 最小权限原则, 特权自动化, 系统安全, 系统提示词, 红帽企业版Linux, 自动化运维, 访问控制, 身份管理, 运维安全, 零信任