Muse Sentinel 逆向工程（2）：实现样例

前面一篇分析了 Muse Sentinel 的实现技术：Muse Sentinel 逆向工程：构建内核级 AI Agent 安全网关

本篇介绍了 sentinel 的实现样例，样例代码请取：sentinel

1 环境

本地 windows 11 + docker desktop 作为验证环境：

验证环境示意

2 构建

构建镜像可以选取安装了 LLVM 18 和 golang 1.25+ 的 ubuntu 24.04 镜像，基于项目的 docker/Dockerfile 进行构建。

3 部署

可以使用 docker/compose.yaml 进行部署（需要第 2 步构建的镜像名为 sentinel:latest）,部署后显示容器为：

运行容器

其中 sentinel 容器为特权容器。agent 容器为被治理的无特权容器，用来模拟systemd-nspawn。

3.1 启动 sentinel

进入 sentinel 容器执行：

mkdir -p /sys/kernel/tracing
mount -t tracefs none /sys/kernel/tracing

因为这里 sentinel 运行在容器里，需要在容器内部手动挂载 Linux 内核的 tracefs 文件系统，以便使用 ftrace 等内核追踪工具。

然后再执行启动 sentinel 守护进程：

sentinel --config /etc/sentinel/sentinel-verify.yaml

启动信息

3.2 挂载 agent 容器的 cgroup

这里需要手动挂载 agent 容器的 cgroup。

• 首先在宿主机上先获取容器的PID：

docker inspect -f '{{.State.Pid}}' agent

• 在 sentinel 容器中挂载： 进入 sentinel 容器（因为原终端已经启动了 sentinel，需要再开一个终端），里面有一个 attach-agent.sh 脚本（如果使用命令行会太复杂，感兴趣可以打开脚本看原始命令行），降上一步获取的 PID 进行挂载：

attach-agent.sh 2435

4 验证

4.1 验证冻结

在 agent 容器中访问一个黑白名单外的地址，例如百度（124.237.177.164:80）

demo-agent --target 124.237.177.164:80

然后这里会看到：

这里容器已经被冻结，因为一直不会触发重试。注意这里第一次连接没有被授权被取消了，这个是eBPF的限制：eBPF cgroup 钩子的裁决模型——connect() 进入内核时，钩子程序同步地在系统调用路径上运行，必须立刻返回一个裁决（否则内核会被 hang 住），所以顺序永远是：先拒绝 → 冻结 → 再问人 → 人批了 → 重试才通。

然后我们回到 sentinel 守护进程容器的日志可以看到 agent 容器被冻结了：

然后进入 sentinel 容器另一个终端去查看当前 pending 的请求：

sentinel-cli pending

然后执行放行：

sentinel-cli approve req-2846-1793004467808472643

回到 agent 容器可以看到：

4.2 验证黑白名单

• 验证 Allow 白名单： 进入到 agent 容器终端：demo-agent --target 8.8.8.8:53

• 验证 Deny 黑名单： 进入到 agent 容器终端：demo-agent --target 1.2.3.4:80

sentinel 控制面信息输出：

4.3 验证污点

demo-agent 通过硬编码访问/tmp/sentinel_demo_sensitive.txt文件，配置文件将该路径文件加入到敏感文件列表，然后通过 demo-agent 模拟先访问敏感文件，然后再访问 Allow 白名单地址，进入到 agent 容器终端：

demo-agent --taint --target 8.8.8.8:53

查看 sentinel 执行日志：

然后进入 sentinel 终端进行放行：