pleme-io/blackmatter-selinux

# blackmatter-selinux NixOS SELinux 强制访问控制 —— 内核构建、用户空间工具、适配 NixOS 的引用策略以及容器卷标签。 ## 这为您提供了什么 一个由四个层级组成的 NixOS 模块，每个层级均可独立使用： | 层级 | 功能 | 成熟度 | |---|---|---| | **T1 — 内核** | 编译启用了 `CONFIG_SECURITY_SELINUX*` 的 `pkgs.linux_selinux`；连接 `boot.kernelPackages` | 实质可用 | | **T2 — 用户空间 + init** | 安装 policycoreutils/libselinux，渲染 `/etc/selinux/config`，systemd 自动重新标记钩子，内核命令行 | 实质可用 | | **T3 — 适配 NixOS 的策略** | 知道 `/nix/store` 路径的引用策略；按服务划分的模块；激活时的重新标记 | **仅包含框架** — 策略模块需要数月时间积累 | | **T4 — 容器卷标签** | 将 podman / docker 的 `:Z` / `:z` 连接到内核；类型为 `container_t` / `container_file_t` | 依赖 T3 | ## 快速开始 ### Permissive 模式的研究测试机（仅限 T1 + T2） ``` # 在你的 NixOS configuration 中 { inputs, ... }: { imports = [ inputs.blackmatter-selinux.nixosModules.default ]; blackmatter.components.selinux = { enable = true; kernel.enable = true; userspace.enable = true; userspace.bootMode = "permissive"; # T3 policy not enabled — kernel logs every access decision but blocks nothing. }; } ``` 在重建 + 重启后： ``` $ getenforce Permissive $ cat /sys/kernel/security/lsm capability,selinux,landlock,lockdown,yama,integrity,bpf $ ausearch -m AVC | head # every access the kernel saw ``` ### 容器宿主机（T1 + T2 + T3 + T4） ``` blackmatter.components.selinux = { enable = true; kernel.enable = true; userspace.enable = true; userspace.bootMode = "enforcing"; policy.enable = true; policy.modules = [ "${inputs.blackmatter-selinux}/policy/modules/podman-host" ]; containers.enable = true; containers.podman.relabelVolumes = true; }; ``` `podman run -v /srv/data:/data:Z …` 现在会将 `/srv/data` 重新标记为 `container_file_t`，并且正在运行的容器进程将获得 `container_t` 类型。 ## 内容位置 ``` flake.nix # consumes substrate's blackmatter-component-flake module/nixos/ ├── default.nix # composes T1–T4, gates each behind enable flags ├── kernel.nix # T1 → docs/T1-KERNEL.md ├── userspace.nix # T2 → docs/T2-USERSPACE.md ├── policy.nix # T3 → docs/T3-POLICY.md └── containers.nix # T4 → docs/T4-CONTAINERS.md module/home-manager/ # researcher tools (secilc, sesearch, audit2allow) overlays/kernel-selinux.nix # alias for the substrate-built overlay policy/ # T3 deliverable ├── modules/ │ ├── nixos-base/ # systemd, kernel, syslog (base.te + base.fc) │ ├── nix-store/ # /nix/store labeling │ └── podman-host/ # rootless podman host policy (ported from container-selinux) ├── README.md # how to author a new policy module └── build.nix # checkmodule + semodule_package pipeline checks/ ├── vm-selinux-permissive.nix # T1+T2 boot test └── vm-selinux-podman-mcs.nix # M3 gate — cross-container isolation proof docs/ # operator runbook + per-tier deep-dives ├── README.md # docs index ├── T1-KERNEL.md ├── T2-USERSPACE.md ├── T3-POLICY.md ├── T4-CONTAINERS.md ├── OPERATOR-RUNBOOK.md # day-to-day ops + recovery └── AUDIT2ALLOW-WORKFLOW.md # policy-authoring loop ``` 有关深入的操作细节，请从 [`docs/README.md`](./docs/README.md) 开始。 ## 复合钩子（无论 SELinux 结果如何的底层基础设施收益） 即使仅使用第 1 层，也能产生可复用的底层原语： 1. **`substrate/lib/build/nixos/kernel-lsm.nix`** — 通用的 参数化 kernel-with-LSM 构建器。可复用于 Landlock、eBPF-LSM， 以及任何未来的 LSM 堆叠工作。 2. **NixOS VM 测试安全模块工具** — 位于 `checks/vm-*.nix` 中的模式，作为任何 `blackmatter-*` 安全组件的 规范模式提升至底层。 3. **arch-synthesizer 中类型化的 `SecurityPosture` 插槽**（M6，参见 理论文档）。集群声明在类型系统中携带其 LSM 选择。 4. **支柱 11 审计告警层。** 每台 `selinux=enforcing` 主机 都会自动获取一个通过 Vector → VictoriaLogs → Alertmanager 连接的 AVC 拒绝激增告警。 ## 状态 | 里程碑 | 状态 | 仓库状态 | |---|---|---| | M0 — 仓库建立，T1 实质可用，T2/T3/T4 为存根，CI 通过 | **进行中** | 本次提交 | | M1 — rio 在 permissive 模式下采用 T1+T2 | 等待 M0 | — | | M2 — 基础策略（systemd + sshd + nix-daemon + journald） | 等待 M1 | — | | M3 — podman 策略 + T4 | 等待 M2 | — | | M4 — rio 实施强制 | 等待 M3 | — | | M5 — 推广至 akeyless-dev / openclaw | 等待 M4 | — | | M6 — `SecurityPosture` 类型体系原语 | 等待 M5 | — | ## 承诺账本 —— 每个里程碑实际闭环的内容 以下威胁来自 [`pleme-io/theory/SELINUX-NIXOS.md` §"Threat model"](https://github.com/pleme-io/theory/blob/main/SELINUX-NIXOS.md)。✅ 表示某个里程碑*作为可推导、可证明的属性*闭环了该威胁（不仅是“我们尝试去做了”——而是有 CI 门禁证明它）。⚠️ 表示部分闭环/仅记录日志。 | 威胁 | M0 | M1 | M2 | M3 | M4 | M5 | |---|:-:|:-:|:-:|:-:|:-:|:-:| | **#1** 通过内核漏洞进行容器逃逸 → 受限于 `container_t` | ❌ | ⚠️ 日志 | ⚠️ 日志 | ✅ | ✅ | ✅ | | **#2** 容器内的应用被攻陷 → 受限于域 | ❌ | ⚠️ 日志 | ⚠️ 日志 | ✅ | ✅ | ✅ | | **#3** 卷挂载配置错误 → 跨容器访问被阻止 (MCS) | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | | **#4** 卷上的符号链接攻击 → 被文件标签阻止 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | | **#5** 宿主机内的进程注入 → 被域 + MCS 阻止 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | | **#6** 单层防御失效 → 其他层进行保护 | ❌ | ❌ | ❌ | ⚠️ podman | ✅ 所有 rio 服务 | ✅ 集群范围 | | 用于合规性证明的审计日志证据 | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | | 可复现的策略构建 (Nix derivation) | — | — | ✅ | ✅ | ✅ | ✅ | | 通过 `nixos-rebuild switch --rollback` 实现的原子策略回滚 | — | — | ✅ | ✅ | ✅ | ✅ | | 类型化的集群范围策略一致性 | — | — | — | — | — | ✅ | **图例。** ✅ = 附带 CI 证明闭环。⚠️ 日志 = 拒绝记录在审计日志中（适用于取证 + 合规审计）但未被阻止。⚠️ podman = 仅针对 podman 宿主机工作负载类别闭环；其他工作负载仍为单层防御。❌ = 未闭环；威胁依然存在。 **诚实的解读：** 直到 M3 发布且 `vm-selinux-podman-mcs` 测试不再被标记为 `meta.broken = true`，其他代理分析中所称的深度防御承诺仍停留在*路线图*中，而非*运行代码*中。任何基于此仓库做出安全决策的人都应首先查看此表。 ### 如何在客户 / 合规语境中解读此表 - **“我们受到 SELinux 保护了吗？”** → “我们拥有一项强制模式的 SELinux 策略，闭环了针对 podman 工作负载的威胁 #1–#5（根据由 `nix build .#checks.x86_64-linux.vm-selinux-podman-mcs` 验证的 M3 交付物）。其他工作负载类别将随着其策略模块的发布而逐步纳入保护。” - **“向我展示证据。”** → `nix flake check` 运行每一个 CI 门禁；`vm-selinux-*.nix` 输出即为字面意义上的证明。 - **“与 Fedora CoreOS 的差距是什么？”** → 参见理论文档中的 FCOS 比较部分；一旦 M3 发布，剩余的差距在于策略成熟度（随着时间推移，按服务划分的策略会逐步闭环），而不是架构。 ## 许可证 MIT —— 与 pleme-io 其余的开源底层项目保持一致。

标签：DevSecOps, DNS解析, Docker, JSONLines, Linux内核, LSM, MAC, Nix Flakes, NixOS, Podman, SELinux, Type Enforcement, Web截图, 上游代理, 内核编译, 安全模块, 安全策略, 安全防御评估, 容器安全, 开源项目, 强制访问控制, 提示词设计, 操作系统安全, 文件上下文标签, 用户空间工具, 系统初始化, 系统加固, 网络安全, 请求拦截, 隐私保护, 零信任