框架告诉我沙箱已应用。我想寻求第二意见，于是询问了内核。
$ grep 安全计算模式 /proc/10920/status /proc/10922/status
/proc/10920/status:安全计算模式: 0
/proc/10920/status:安全计算模式过滤器: 0
/proc/10922/status:安全计算模式: 2
/proc/10922/status:安全计算模式过滤器: 1
10920 是代理进程。10922 是其派生出来运行由模型编写的代码的工作进程。工作进程加载了安全计算模式过滤器，而父进程没有。这就是网络阻断机制，它仅应用于理应拥有该机制的进程，而不影响其他任何进程。
这花费了十秒钟，这是在整个项目中，我首次通过程序自身报告以外的手段进行验证的事项。
我在做什么
我运行的是执行由语言模型编写代码的人工智能代理框架。英伟达的 NOOA 是我一直在研究的框架。其文档异常直白：静态检查和拒绝列表仅是防护栏，而非隔离边界，真正的边界是操作系统级别的隔离。
它确实提供了一套隔离机制。每一块生成的代码都在一个派生的工作进程中运行，其中 Landlock 限制文件系统访问，安全计算模式阻断网络套接字，同时设有资源上限和硬性超时限制。其论文的附录 D.2 描述了该机制的部署情况，包括其进程内防护中已知存在的缺口，以及作为后备措施捕获该缺口的机制。
因此，问题不在于设计是否合理。设计是合理的。问题在于，论文中描述的机制是否真的在我的机器上运行。
第一个意外
并没有。
execution_backend: 字面量["进程内", "沙箱"] = "进程内"
操作系统沙箱需要显式启用。我之前进行的每一次代理运行，都是在代理自身的进程中执行由模型编写的 Python 代码，仅受抽象语法树验证器和拒绝列表的保护，而文档明确告知这些并非隔离边界。
没有任何错误。我构建的虚拟机正在执行工作，这正是自述文件指示的操作。但我假设存在这一层隔离，因为我阅读过其源代码，而阅读源代码并不等同于检查实际运行的内容。
内核会告诉你会不会告诉你什么
启用后，防护措施变得可检查。但并非所有措施都以相同方式检查。
安全计算模式 可按进程读取。这就是上述差异所在，也是可用的最强证据：由内核报告进程状态，而非进程自我报告。
资源上限 在两个进程中均显示为无限制。这看起来像是一个发现，直到我阅读了配置：max_memory_mb（最大内存兆字节数）和 max_cpu_seconds（最大中央处理器秒数）均默认为 0，这意味着禁用。未请求任何限制，因此未应用任何限制。配置与内核状态一致。我只是没有阅读配置。
Landlock 完全无法回读。一旦进程应用规则集，限制即为真实且不可撤销，但 /proc 中没有对应的字段。差异对比技巧在此无效。确认它的唯一方法是行为测试：让受限的
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
