# 💡Summary > [!Info] > 一句话说清楚 > 对，你的理解非常准确。 **全称是 Secure Computing Mode**，直译就是"安全计算模式"，是 Linux 内核从 2.6.12 版本（2005年）就内置的一个功能。 它确实是**操作系统内核级别**的权限控制，而且是目前最底层的一道防线——不是应用层的权限检查，不是文件系统的权限位，而是在**进程和内核之间的入口处**设卡。 一个简单的类比： > 操作系统就像一栋政府大楼，系统调用是大楼里的各个办事窗口（开文件、建网络连接、创建进程……）。Namespace 是给你发了一张"你只能看到这几个房间"的地图，cgroup 是规定"你每天只能消耗这么多资源"，而 seccomp 是在大楼门口直接把你的"危险申请单"没收——某些窗口你根本连排队的资格都没有。 它的层级关系大概是这样： ``` 应用代码 ↓ C 标准库（glibc） ↓ 系统调用接口（syscall） ← seccomp 守在这里 ↓ Linux 内核 ↓ 硬件 ``` 所以即使攻击者突破了应用层的所有防御，只要 seccomp 规则设计得好，他能做的事情依然极其有限——连"打电话给内核"的很多功能都被直接切断了。这也是为什么它被广泛用在浏览器沙箱（Chrome 也用）、容器运行时、代码执行引擎这类场景里。 ## ai会不会自己改写seccomp 这是个非常好的安全问题，答案是：**想改，但改不了**。原因是 seccomp 的设计有一个关键特性： #### 规则一旦加载，进程自己无法撤销 seccomp 过滤器通过 `prctl()` 这个系统调用来设置，但它遵循一个**单向棘轮原则**： ``` 只能加更严格的规则，不能放松已有的规则 ``` 也就是说，沙箱启动时内核就把规则锁死了。AI 代码运行在沙箱进程里，如果它尝试： - 调用 `prctl()` 修改 seccomp 规则 → 这个 syscall 本身就在黑名单里，直接被拦截 - 写内核内存来绕过规则 → 需要 `mmap`/`ptrace` 等特权调用，也在黑名单里 - 创建子进程来逃脱 → 子进程**继承**父进程的 seccomp 规则，逃不掉 #### 谁能改规则？ ``` AI 代码进程 ✗ 没有权限 root 用户进程 △ 要看规则是否设了 NO_NEW_PRIVS 内核本身 ✓ 但 AI 碰不到内核 启动沙箱的程序 ✓ 在沙箱创建之前设置 ``` #### 唯一的威胁：内核漏洞 理论上如果内核本身有未修补的漏洞（比如某个 CVE），AI 代码可以通过精心构造的 syscall 参数触发内核 bug，从而拿到内核执行权限，进而绕过一切限制。这叫**内核提权（privilege escalation）**。 但这不是"改写 seccomp"，而是"让 seccomp 还没来得及拦截就已经出事了"。这也是为什么 Sandbox Fusion 这类方案还会叠加 cgroup、namespace，多层防御——单点被突破不等于全盘失守。 所以简单说：**AI 在规则的管辖范围内根本看不见 seccomp 的存在，更谈不上修改它，这是设计上就保证的。**