AI 排障翻车复盘:Codex 沙箱 ACL 的视野盲区

日期: 2026-10-09 机器: 工作机(Windows 26H1,企业终端管控软件管控) 关联场景: 同期的 AI 协作与终端加固讨论

一、事件档案

1.1 症状(今天集中爆发)

双击打开桌面程序弹"打开文件 - 安全警告:无法验证发布者"(微软签名的记事本副本也弹);
程序图标全部变白页;
移动/编辑/压缩用户目录下的文件也弹确认框;
部分程序点击"运行"后仍无法正常打开。

1.2 真实根因(实测确认)

Codex 系 AI 编码工具的 Windows 沙箱,把它的 ACL 模板套在了整个 %USERPROFILE%\Desktop 目录树上。

桌面文件夹上被写入的非标准安全描述符:

Everyone:(DENY)(DC)                              ← 拒绝删除
S-1-4-<本地标识>:(OI)(CI)(W,D,DC)      ← 非标准 SID 获写/删除权
<机器名>\CodexSandboxUsers:(OI)(CI)(RX)   ← Codex 沙箱组
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) ← 低完整性标签,继承给全部子文件

关键机制链:

文件被继承打上 Low Mandatory Level(低完整性)标签 → Windows 沿用 IE 保护模式时代的信任语义,把低完整性文件视为"来自互联网的不可信来源" → Explorer 对这些文件的启动一律走附件管理器警告(“无法验证发布者”,签名有效也无效), 不加载内容图标(白页),移动/压缩等操作也弹确认。

完整因果链的每一环都由此闭环:为什么签名无效、为什么图标变白、为什么只有 C 盘用户目录触发(只有桌面树被套模板,TEMP/用户根/D 盘标签正常)、为什么移动文件也弹。

1.3 时间线

时间	事件
2026-09-16 18:29	CodexSandboxOffline/Online 沙箱账号创建(Codex 系工具入驻本机)
无日志可查	某次以桌面为工作区的沙箱会话,将 ACL 模板套上桌面目录树
2026-10-08	症状集中爆发;同日机器重启 9 次(期间还在用 AI 工具排查,可能反复触发)
2026-10-08 晚	本轮排障,定位并修复

1.4 叠加因素(独立事件,已顺手处理)

桌面另有 897 个带"网络下载标记"(Mark of the Web)的文档,移动/压缩时同样弹窗——Windows 原生行为,已批量解除锁定;
Snipaste"绑定快捷键失败"为故障会话残留状态,干净重启后自愈;
误诊期间曾怀疑该 EDR DLP(它确实向 Explorer 注入了钩子 DLL),最终证明与本症状无关——但注入事实本身值得另案记录。

1.5 修复动作

移除桌面文件夹上的 3 条沙箱 ACE + 完整性标签 Low→Medium(继承自动传播到全部子文件),重启 Explorer 刷新图标缓存。自动化终测:桌面 exe 直接启动、零弹窗。原 ACL 已备份至 Temp\desktop_acl_backup.txt。

二、为什么 AI 会一直在错误的方向(核心复盘)

当时排障的 AI(VSCode 的 Claude Code 插件,DeepSeek 底座)从"杀软误报"开始,长期在错误方向打转。不是单一原因,是五层结构性因素叠加:

2.1 行动者对自己的副作用失明(最核心)

肇事的就是 AI 工具链自己的沙箱。但沙箱的副作用不进任何一方的能力范围:

沙箱改的是文件系统元数据(ACL/完整性标签),不是文件内容——AI 平时读写文件、列目录,全都感知不到这层;
沙箱没有"我修改过哪些目录的安全描述符"的记账,事后无法回溯;
于是当用户报告症状时,AI 面对的是一个被自己污染过的现场,而它的观测通道里现场是"干净的"。

行动者无法看见自己的副作用,这不是 DeepSeek 的缺陷,是当前 AI agent 工具链的结构性缺陷:副作用记账不完整。

2.2 无先例的根因,检索式推理必然失效

LLM 的归因本质是语料中的常见关联匹配:杀软误报、SmartScreen、组策略、UAC、下载标记、AppLocker……这些是"程序弹安全警告"的高频答案。而"某个 AI 工具给桌面目录打了低完整性标签,导致全目录文件被系统视为不可信来源"——这种案例在公开语料里几乎没有先例。

文本检索式推理,找不到训练分布里不存在的根因。这不是推理错了,是武器库里没有这发子弹。 唯一能找到它的方法不是"想",而是"测"——对系统状态做实测对比。

2.3 缺了差分诊断这个动作

最终破局靠的是差分:用户观察到"只有 C 盘用户目录下的东西出问题"→ 立刻做**坏位置(桌面) vs 好位置(TEMP/D 盘)**的同内容文件 ACL 对比 → 沙箱 ACE 和 Low 标签一行现形。

之前的排障一直在做"枚举常见原因、逐个排除"(杀软→SmartScreen→UAC→组策略→下载标记),这是清单式排查。差分诊断(找一个正常参照物,对比状态)永远快于清单排查,而 AI agent 很少自发做这个动作——需要在提示里明确要求。

2.4 GUI 层的关键证据只有用户能提供

弹窗的原文措辞、图标的白页状态——这些证据不存在于任何日志文件里,只存在于屏幕上。AI 的工具拿不到它们。本案三次转折点全部来自用户的人工观察:

用户观察	作用
“弹窗是 win 的弹窗,该 EDR策略是 9 月的”	推翻了杀软方向的锚定
“图标都变成白页了”	指向"Explorer 读不了文件内容",一步锁向 ACL/标签
“出问题的都在 C 盘用户目录下”	确立差分诊断的对比对象

2.5 锚定效应与补丁式假设

第一个合理解释(杀软误报)建立后,后续每次反证都被处理成"再排除一个嫌疑项",而不是"整个问题模型可能错了"。正确姿势:当连续 2~3 个假设被证伪,应当回头质疑问题的默认框架(“是否默认这是外部恶意/系统故障?会不会是某个工具留下的正常副作用?")。

三、AI 使用坑清单(防复发,可操作)

带沙箱的 AI 编码工具,工作区别指用户常驻目录(桌面/文档/项目根)。它为沙箱进程套用的 ACL/标签模板会改变这些目录里所有文件的系统信任属性;
症状出现先做变更盘点,再找原因:最近装/跑过什么工具、重启几次、哪些工具有沙箱/驱动/服务——本案 9 次重启期间恰好在跑 AI 工具;
要求 AI 做差分而不是枚举:“找一个没问题的同类位置,和出问题的位置逐项对比状态”;
GUI 层观察人工带给 AI:弹窗原文、图标颜色、出现规律(哪些目录/哪些操作),这些是 AI 的天然盲区;
连续证伪 2~3 个假设后,强制换框架,不再打补丁;
企业管控机器排障第一步是盘点拦截者:本机实际状态是国产安全软件仅残留(未运行)、Defender 被该 EDR接管、该 EDR DLP 向 Explorer 注入钩子——“以为的防护栈"和"实际在跑的"经常不一致;
AI 会误诊,你也会误判 AI:给 AI 的观察必须是原始事实(看到什么),不要掺入自己推测的结论(如"是不是杀软拦了”),否则会强化它的锚定。

四、数据安全视角的技术沉淀

完整性级别(IL)是 Windows 信任链的一等公民:Low IL 文件被 URLMON/Explorer 按"互联网来源"信任语义处理(IE 保护模式遗产)。文件不带任何 MotW 也可以因低 IL 走不可信路径——信任判断看的是元数据,不只是内容;
AI 工具的本地权限治理应纳入终端加固清单:沙箱基础设施(本地用户组、ACL 模板、注入钩子)拥有修改用户文件信任属性的能力,且无审计日志。同时接入多网的高价值工作终端,应把"AI 工具沙箱的工作区白名单"与自有终端加固清单并列;
检测思路(可落地):对用户常驻目录做 icacls /save 基线,定期比对安全描述符与完整性标签的漂移——“谁给 Desktop 打了 Low IL"这类事件本应被配置漂移检测捕获;
延伸思考:低 IL 标签 + 沙箱组若被滥用(把敏感目录伪装为低信任以绕过某些仅校验读权限的控制,或借沙箱组 ACE 放行),即构成真实的访问控制风险。AI 工具供应链的本地 footprint 是数据安全的新审计对象。

五、一句话教训

AI 排障的第一问不该是"常见原因有哪些”,而是"这台机器最近发生了什么变化”; 而带沙箱的 AI 工具,恰恰就是那个最容易被所有人(包括它自己)忽略的变化。

六、背景知识速查(沙箱 / ACL / 波及范围取证)

6.1 沙箱是什么,和 AI 模型的关系

AI 模型(DeepSeek 等)本身只是"生成文本的发动机",没有任何权限,碰不到你的电脑。真正在你机器上执行命令的是宿主程序(VSCode 插件 / Codex CLI 这一层):模型说"运行 xxx",宿主负责真跑。

沙箱就是宿主给这些命令套的隔离服:不使用你的管理员身份,而是创建受限的本地账号(本机即 CodexSandboxOffline/Online,9-16 创建),让命令以最低权限身份执行——模型万一发疯或被提示词注入,破坏面也小。

类比:模型是指挥室里的大脑,沙箱是执行机器人穿的防护服。问题在于:防护服要摸工作区的文件,就得给防护服发门禁卡——而"发门禁卡"(改 ACL/标签)本身就是对系统的修改,且这一步不询问、不通知、不留审计日志。

6.2 ACL 与完整性标签

ACL(Access Control List):每个 NTFS 文件/文件夹自带的权限清单,逐条记录谁可读/写/执行/删除(每条叫一个 ACE)。文件属性→“安全"选项卡看到的就是它。类比:门禁卡名单。
完整性标签(Mandatory Label):ACL 之外的独立信任标记,分低/中/高。规则是"低信任进程不许改高信任数据”(no-write-up)。类比:洁净室等级。
事故机理:沙箱的进程是低权限的,为了让它能写你的文件,模板把桌面整个区域的洁净室等级改成了"低"——但 Windows 对"低等级区域里的程序文件"一律按不可信来源对待,于是弹窗、白图标全来了。沙箱为了安全设计的行为,触发了 Windows 另一套安全设计的误判。

6.3 波及范围取证(为什么是整个桌面)

修复后对桌面下全部 257 个子文件夹做了指纹扫描:没有任何子文件夹携带沙箱 ACE 残留或 Low 标签。

结论:沙箱 ACL 模板当初只套在 %USERPROFILE%\Desktop 根上,靠 (OI)(CI) 继承扩散到全树;不是套在某个项目文件夹上再扩散的。工具选择 ACL 目标的依据一般是会话的工作区根目录,故最可能的情形是某次会话的工作区根恰好是桌面本身(典型:桌面右键"在终端中打开"后启动工具 / VSCode 打开的文件夹选了桌面 / 未指定文件夹时的默认回退)。

既非有意的误操作,也非 AI 恶意偷干——是宿主的静默默认行为:套 ACL 是沙箱运作的必要动作,但设计上无确认、无通知、无日志。

可操作结论:给带沙箱的 AI 工具指定工作区时,使用专门的一次性目录(如 D:\AIWork),永远不要让工作区根落在桌面、文档等常驻目录——模板再来也只污染一次性目录。

6.4 继承是谁做的,怎么理解

责任分两层:继承的机制是 Windows NTFS 的设计(NT 团队,1993 年起就有),继承的启用是 Codex 宿主——它调用标准安全 API,在桌面文件夹这一处写入一条带 (OI)(CI) 标志的 ACE,Windows 负责把这条 ACE 传播到整棵树。Windows 提供了复印机,Codex 放上了错误的底稿。

ACE 上的标志位:

标志	含义
(OI) 对象继承	这条规则传给文件夹内的文件
(CI) 容器继承	这条规则传给子文件夹(并继续向下传)
子项上的 (I)	表示"这条规则是从父目录继承来的副本",不是直接设置在本项上

理解继承的关键:它是"复制",不是"每次访问时动态向上查询"。套用那一刻,Windows 把父目录的 ACE 复制到每个子项的安全描述符里;之后新文件一出生就自动盖上副本;访问文件时只读自己的安全描述符,不回溯父目录,所以效率高。

类比:物业在小区门口贴一条新门禁规定,(OI)(CI) 意味着自动复印一份贴到每栋楼、每个房间,以后新建的楼也自动贴;物业改了总规定,所有副本同步更新;单个房间可以声明"规定独立"(断开继承,即文件属性→安全→高级里的继承开关)。

对应本案,成也继承败也继承:

Codex 必须用继承:工作区里会不断产生新文件,继承保证每个新文件落地即对沙箱进程可访问——不用继承,今天能用明天就失效,工作区语义崩塌。用继承是正确工程,对哪个目录用才是错误;
伤害也因此是全树的:同一个机制把 Low 标签复印到了 8 万个文件上;
修复因此也只需一刀:改桌面根一处为 Medium,Windows 自动同步全部子项——修复走的正是污染的同一条通道反向。

七、拓展与联想:ACL 的前世今生与三大流派

7.1 思想源头

Multics(MIT+贝尔实验室+GE,1965 起):第一个把"保护"当作 OS 核心设计的系统,引入保护环与分段访问控制列表;
Lampson 访问矩阵(1971《Protection》):把安全形式化为矩阵——行=主体,列=客体,格=权限。矩阵怎么存储衍生出两大流派:
- 按列存(每个文件挂一张"谁能访问我"的清单) = ACL;
- 按行存(每个进程持有一组钥匙) = 能力机制(capability)——今天的容器 seccomp、iOS entitlements、浏览器权限弹窗都是它的后裔。

7.2 三大平台实现对照

	模型	默认形态	特色
Linux	DAC + 可选 MAC	`rwx` 权限位 + umask;ACL 为可选项(getfacl/setfacl,POSIX 1003.1e)	SELinux(NSA,2003 入内核)走 MAC 强制访问控制;Ubuntu 系常用 AppArmor
Windows	DAC + 轻量 MAC	最彻底的 ACL 中心主义:DACL 授权 + SACL 审计,有继承、Deny 优先、显式覆盖继承	NT 3.1(1993)带入主流,团队核心 Cutler 出自 VMS;Vista(2006)加入完整性级别 MIC(即本案标签)
macOS	DAC + MAC + 隔离标记	POSIX 权限位 + 增强 ACL(10.4 起);TrustedBSD MAC 框架支撑 App Sandbox 与 SIP	com.apple.quarantine 隔离属性 = macOS 版"下载标记"(Gatekeeper 据此拦截);Linux 默认无对应物

结论:三大平台都是"访问矩阵"这一个理念的后代,取舍不同;本案的低完整性标签属于 MAC 路线的轻量实现。

7.3 DAC 与 MAC:两条哲学路线

DAC(自主访问控制):资源属主决定授权(权限位/POSIX ACL/NTFS DACL)。灵活,但属主可以随手乱给;
MAC(强制访问控制):系统策略说了算,属主改不了(SELinux/完整性标签/SIP)。不可绕过,但策略写错全体遭殃。

本案定性:Codex 为实现自己的 MAC 需求(让低权限沙箱进程能写工作区),滥用了 Windows 的 DAC 通道(给用户文件打低完整性标签),最终撞上了第三套机制——附件管理器的"低完整性 = 不可信来源"信任语义。一次行为,三套安全设计互相碰撞,每一套单看都合理。

7.4 因果链复述练习(我的总结 vs 修正)

我的原话:“Codex 为了安全设计了沙箱访问,我一次使用时图方便让它指向了整个桌面,后续没有指令,Windows 的 DAC 通道将这一沙箱递归打标签给了所有桌面上的文件,最终与 Windows 的安全原则发生冲撞,造成日常使用权限混乱无法操作。”

修正版:“Codex 为安全而设计沙箱;某次使用时工作区根指向了桌面。其宿主在会话启动时,为让低权限沙箱进程能读写工作区,通过 ACL 与 (OI)(CI) 继承标志对桌面目录树一次性写入沙箱 ACE 和低完整性标签;这个低完整性标记撞上了 Windows 附件管理器的信任语义(低完整性=不可信来源),于是桌面全部文件被按不可信处理——反复弹确认框、图标白页、部分程序启动被拒。”

四处关键修正:

施动者是 Codex 宿主程序,Windows DAC 只是通道/载体——安全事件报告里施动者搞错,整个事件定性就错;
“递归"实为 (OI)(CI) 继承标志驱动的一次性树传播,发生在套用那一刻——知道是一次性写入,才会去查目录 ACL 本体而非找"持续打标签的东西”;
冲撞对象是附件管理器的信任语义这一具体机制——定位到具体机制,才知道修复杠杆在哪(改标签);
后果是信任被降级(反复确认+白图标+部分启动被拒),不是权限意义上的"无法操作"——DACL 权限与完整性标签是两套机制,术语用对,下次排查就不会跑错楼层。

7.5 延伸阅读

Butler Lampson, Protection (1971)——访问矩阵,ACL 与能力机制共同的理论原点;
Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations (1966)——能力机制开山;
Saltzer & Schroeder, The Protection of Information in Computer Systems (1975)——八原则(经济性机制、失败安全默认、完全仲裁、最小特权……),写加固方案可直接引用,双网加固文档的每条措施都能对应到其中至少一条。

一、事件档案#

1.1 症状(今天集中爆发)#

1.2 真实根因(实测确认)#

1.3 时间线#

1.4 叠加因素(独立事件,已顺手处理)#

1.5 修复动作#

二、为什么 AI 会一直在错误的方向(核心复盘)#

2.1 行动者对自己的副作用失明(最核心)#

2.2 无先例的根因,检索式推理必然失效#

2.3 缺了差分诊断这个动作#

2.4 GUI 层的关键证据只有用户能提供#

2.5 锚定效应与补丁式假设#

三、AI 使用坑清单(防复发,可操作)#

四、数据安全视角的技术沉淀#

五、一句话教训#

六、背景知识速查(沙箱 / ACL / 波及范围取证)#

6.1 沙箱是什么,和 AI 模型的关系#

6.2 ACL 与完整性标签#

6.3 波及范围取证(为什么是整个桌面)#

6.4 继承是谁做的,怎么理解#

七、拓展与联想:ACL 的前世今生与三大流派#

7.1 思想源头#

7.2 三大平台实现对照#

7.3 DAC 与 MAC:两条哲学路线#

7.4 因果链复述练习(我的总结 vs 修正)#

7.5 延伸阅读#