rajan-sharma-in/linux-container-security-verifier
GitHub: rajan-sharma-in/linux-container-security-verifier
该项目是一个基于 Linux 「/proc」文件系统的极简 CLI 工具，用于验证运行中进程实际生效的容器安全控制状态，弥补 Kubernetes 策略声明与内核真实执行之间的验证空白。
Stars: 0 | Forks: 0
# Linux Container Security 验证器
Linux Container Security Verifier 是一个小型开源 CLI 工具，用于检查正在运行的进程是否实际启用了 Linux 级别的容器安全控制。它特意设计得非常精简，适用于学习、演示和 Linux 安全讨论，包括 Linux Security Summit CFP 的演示。
该 verifier 直接读取 `/proc/`。它不会询问 Kubernetes、Docker、containerd 或策略引擎应该发生什么。它检查的是 Linux 内核为正在运行的进程所暴露的实际状态。
## 为什么要验证 Kubernetes Policy 之下的状态
Kubernetes 安全设置、准入策略、Helm 值和 CI 检查非常重要，但它们只是意图。最终的执行状态存在于 Linux 原语中，例如 capabilities、seccomp、LSM 标签、挂载标志和 user namespaces。
运行时默认设置、CRI 实现细节、特权 pod、hostPath 挂载、init 系统或手动启动的容器，可能会导致实际生效的 Linux 状态与团队预期的策略不同。这款工具提供了一种快捷的方法，用于将声明的加固措施与内核可见的执行信号进行比较。
这是一个 verifier，而不是策略引擎。它报告来自 Linux 进程状态的检查结果，并在 `/proc` 无法证明完整运行时上下文的地方使用保守的启发式方法。
## 检查内容
对于目标 PID，verifier 会检查：
- `/proc//status`
- `CapEff`：有效的 Linux capabilities，解码为 capability 名称
- `NoNewPrivs`：是否阻止了获取特权的 exec 转换
- `Seccomp`：是否激活了 seccomp 过滤
- `NSpid`：PID namespace 映射（如果可用）
- `Uid` 和 `Gid`：进程凭证 ID
- `/proc//attr/current`
- AppArmor 或 SELinux 标签（如果可用）
- 包含 `unconfined` 的标签将被视为失败
- `/proc//mountinfo`
- 可写的敏感路径，例如 `/`、`/proc`、`/sys`、`/dev`、`/etc`、`/run` 和 `/var/run`
- 类似于宿主机的挂载源或目标，可能表明存在 hostPath 暴露
- `/proc//uid_map`
- 可能的身份用户 namespace 映射
- 直接的 `0 0 ...` 映射会被标记为可能的 container-root-to-host-root 映射
检查结果分类为 `PASS`、`WARN`、`FAIL` 或 `INFO`。
## 构建
```
go build -o verifier ./cmd/verifier
```
你也可以在不构建的情况下运行它：
```
go run ./cmd/verifier --pid
```
## 针对任意 Linux 进程运行
```
sudo ./verifier --pid 1
```
可选标志：
```
sudo ./verifier --pid --json
sudo ./verifier --pid --strict
sudo ./verifier --pid --verbose
```
退出码：
- `0`：没有 `FAIL` 发现
- `1`：有一个或多个 `FAIL` 发现
- 带有 `--strict` 的 `1`：有一个或多个 `FAIL` 或 `WARN` 发现
- `2`：工具或运行时错误，例如无效的 PID 或缺少 `/proc/`
## 针对 Kubernetes 容器进程运行
verifier 需要容器进程的宿主机 PID。对于 CRI 运行时，`crictl` 通常是最快的方式：
```
crictl ps
crictl inspect | jq '.info.pid'
sudo ./verifier --pid
```
如果你的运行时将应用程序进程嵌套在 shim 或 pause 进程之下，请检查进程树并选择你要验证的工作负载进程。
## 针对Docker 容器运行
```
docker inspect --format '{{.State.Pid}}'
sudo ./verifier --pid
```
## Kubernetes Pod 示例
该仓库包含两个示例 pod：
- `examples/pod-privileged.yaml`：故意设计得不安全，包含特权模式、host namespaces、unconfined seccomp 以及对 `/` 的 hostPath 挂载
- `examples/pod-restricted.yaml`：更安全的基线配置，包含非 root 用户、丢弃的 capabilities、`allowPrivilegeEscalation: false`、只读根文件系统和 runtime-default seccomp
将它们部署到一次性的测试集群中：
```
kubectl apply -f examples/pod-privileged.yaml
kubectl apply -f examples/pod-restricted.yaml
```
找到它们的容器 ID 和宿主机 PID，然后运行：
```
sudo ./verifier --pid
sudo ./verifier --pid
```
特权 pod 应该会显示更多的警告或失败，尤其是在 capabilities、seccomp、namespace 暴露和挂载方面。受限 pod 应该具有较少的高风险 Linux 信号，尽管具体结果取决于你的内核、容器运行时和集群配置。
清理：
```
kubectl delete -f examples/pod-privileged.yaml
kubectl delete -f examples/pod-restricted.yaml
```
## 所需权限
某些 `/proc` 文件可能会被内核设置、user namespaces、mount namespaces 或 LSM 策略隐藏或限制。在节点上以 root 身份运行可以获得最完整的视图：
```
sudo ./verifier --pid
```
该工具能够优雅地处理文件缺失和权限被拒绝的错误，通常将其列为 `INFO` 发现，除非缺少必需的运行时路径。
## 局限性
- `/proc` 显示的是进程的内核状态，而不是原始的 Kubernetes 或运行时配置。
- 挂载和 hostPath 检测使用的是启发式方法，因为 `mountinfo` 不包含完整的 Kubernetes 数据卷源对象。
- `uid_map` 身份映射是强烈的信号，但 user namespace 的解释应通过运行时元数据来确认。
- Capability 风险取决于工作负载的上下文。该工具突出了宽泛和高风险的 capabilities；它不能替代威胁模型。
- 该 verifier 不执行策略、修改工作负载，也不证明工作负载是安全的。
标签：EVTX分析, Linux内核, Web截图, 子域名突变, 容器安全, 日志审计, 请求拦截