[Windows] workspace-write 沙箱在工作区留下的常驻 Low 完整性标签有两个下游症状,且每次授权都会重打

[bHorse]

环境

• dsh @deepseek-ai/dsh 0.1.7-rc.1,沙箱后端 @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-rc.1
• Windows 11 中文版(2026-09 补丁),NTFS 数据盘
• 受影响工作区:一个 Python/Streamlit 项目(自带 .venv)、一个含 .venv 的游戏服务端项目
• 沙箱模式:workspace-write(非 --danger-full-access)

一句话

grantWrite 给整棵工作区树(根上 (OI)(CI) 可继承)写入的 Low 完整性标签按设计常驻,
导致两个与"写权限"看似无关的下游症状;并且每次 workspace-write 授权都会重新打标,
所以"清掉了又回来",极易被误诊成 pip / 杀软 / 网络 / 代理问题。

症状(同一根源,三种表现)

① 工作区内 venv 的 exe 启动的进程被降级为 Low 完整性

Windows 会把镜像文件的完整性标签施加给从它启动的进程。典型 Python 项目里,
.venv\Scripts\python.exe 位于被标 Low 的工作区树下 → 进程也是 Low → 写不了工作区外的任何路径
(与 DACL 无关,账户对该路径明明是 Full Control)。Python 的 tempfile 逐个候选目录都因
完整性检查失败,最后回退到 os.getcwd():

TMP/TEMP 环境变量完全正确 (C:\Users\<你>\AppData\Local\Temp)
tempfile.gettempdir() → E:\work\my-project        ← 回退到项目根

于是 pip / pytest / streamlit 的临时目录全部堆在项目根(pytest-of-*、pip-unpack-*…)。
实测 A/B:同一个 python.exe(sha256 相同),标签 Medium 时所有写目标 OK,Low 时除工作区外全 FAIL。

venv 侧的任何 .exe 入口(pip.exe / pytest.exe / streamlit.exe)同理:它们自己带 Low 标签时,
由它们发起的安装/测试全部表现异常;走 python -m pip 反而可能正常 ——
"同一个动作时好时坏"正是这个标签存在与否的差分信号。

② 工作区树里的未签名 exe 被 SmartScreen 拦("无法识别的应用")

工作区里任何一个未签名的 exe(游戏引擎、工具、自编译产物……)双击被 SmartScreen 拦下,
提示"阻止了无法识别的应用启动";同一份字节拷到 C:\ 或任何不带 Low 标签的目录就照常启动。

对照实验(编译一个只 sleep 的无害未签名探针,分别从不同目录启动):

启动位置	完整性标签	结果
C:\Users\<你>\normal\	无(=Medium)	启动 OK
<数据盘>\__probe\(盘根,无标签)	无	启动 OK
同一 exe 的另一份拷贝(无标签目录)	无	启动 OK
沙箱工作过的工作区	Low	被拦

已排除:MotW(全盘 0 个 Zone.Identifier)、Authenticode 签名、文件哈希变化、
云端信誉端点可达性(smartscreen.microsoft.com / wdcp.microsoft.com 对裸 GET 返回 502/503
是端点正常行为,直连与走代理一致)、本机代理。

修复 = 恢复标签:

icacls "<工作区>" /setintegritylevel (OI)(CI)Medium /T /C /Q
# 整树 ~47 秒,0 失败;对正在运行的进程无影响(改的是磁盘上的镜像标签)

修复后同位置探针启动 OK。

两个工程坑,做自动化排查时务必注意:

• SmartScreen 提示是模态的:Start-Process 无超时会永久挂死(等人工答复);
• 人工点"不运行"后抛出的异常,外层 HResult 是 0x80131509(InvalidOperationException),
  真正的 0x800704C7(ERROR_CANCELLED)在内层异常 —— 只按外层判会漏掉这个签名。

③ 每次授权都会重打 → 复发

实测时间线:把某工作区整树清回 Medium(复验过)→ 约 30 分钟后 dsh 在同一工作区又跑了一轮 →
复查:根目录又变 Low(子目录/exe 仍是 Medium,说明重打的是根上那条可继承 ACE,无递归)。
另一个正在使用的 Python 工作区,抽样 308/309 个文件是 Low。

"会话活着"的可观测证据:

• %TEMP%\dsh-* 每 20~40 秒新增一个(dsh-acl-locks、dsh-workspace-changes-* 等);
• C:\Users\<你>\.dsh\sessions\<--盘符-路径-->\ 里的 session.v4.jsonl.zstd 持续更新;
• 进程列表可见 dsh.exe web + node ...\@deepseek-ai\dsh\lib\bin.js web。

项目内脚本、计划任务都不做这件事(全查过,setintegritylevel 零命中)——只有沙箱会写这个标签。

附带发现:Defender 把 dsh 的文件改写判成木马

dsh 通过 runner.js → pwsh -Command 对工作区内 GBK 编码的 .ini/.txt 做
ReadAllBytes / Replace / WriteAllBytes 时,3 次触发 Defender 行为启发式,
记录为 Trojan:Win32/FileFix.BBA!MTB(Severity 5,已阻断清理),Get-MpThreat 至今显示为
"活动威胁"。改写内容完全无害,属误报 —— 但这个"FileFix 式字节级改写"模式正好撞在启发式枪口上,
建议了解:用户侧看到"agent 改了文件却没生效"时,可能其实是 Defender 拦的。

最小复现(不碰任何真实项目)

# 1) 模拟 grantWrite 留下的标签
$T = "$env:TEMP\__lowlabel_demo"
New-Item -ItemType Directory $T -Force | Out-Null
icacls $T /setintegritylevel '(OI)(CI)Low' | Out-Null

# 2) 编一个未签名探针,放进树里 → 自动继承 Low
Add-Type -TypeDefinition 'using System; using System.Threading; public class P { public static void Main(){ Thread.Sleep(8000); } }' `
  -OutputAssembly "$T\probe.exe" -OutputType ConsoleApplication
icacls "$T\probe.exe"        # ← Mandatory Label\Low Mandatory Level:(I)(NW)

# 3) 启动被拦(桌面会弹模态提示;点"不运行"后看异常链)
try { Start-Process "$T\probe.exe" -PassThru }
catch {
  '{0:X8}' -f $_.Exception.HResult                        # 0x80131509(外层,会骗人)
  '{0:X8}' -f $_.Exception.InnerException.HResult         # 0x800704C7(真签名)
}

# 4) 同一份字节,放到无标签目录 → 正常启动
Copy-Item "$T\probe.exe" "$env:TEMP\probe_ok.exe"
Start-Process "$env:TEMP\probe_ok.exe" -PassThru

venv 侧金丝雀(判定一个 Python 工作区是否中招):

.venv\Scripts\python.exe -c "import tempfile;print(tempfile.gettempdir())"
# 输出 = 项目路径   → 进程被标签降级(中招)
# 输出 = 系统 %TEMP% → 正常

对 dsh 的建议

1. 文档:在 workspace-write 说明里写明"会在工作区树上留常驻 Low 完整性标签"并列出下游症状,
   否则用户(以及跑在里面的其他 agent)会顺着 pip/杀软/代理查几个小时。
2. 提供恢复手段:如 dsh sandbox restore-labels --workspace X,或会话结束自动恢复原标签;
   至少给一个"退出后自动清标"选项(--danger-full-access 之外的低成本出路)。
3. 考虑令牌侧收口:既然已是 restricted-token + capability-SID 写允许清单,对象侧 Low 标签对
   "限制沙箱进程"并非必需,副作用却由用户之后在工作区里启动的一切来承担。若有实现依赖,
   建议至少豁免 .venv/Scripts/*.exe 这类会被用户直接启动的运行时镜像。
4. 前置条件报错可读性:工作区所有者缺 WRITE_OWNER 时(数据盘卷根没有 CREATOR OWNER 继承、
   新建目录只有 Modify 的机器很常见),SetNamedSecurityInfoW failed (Win32 5): grantWrite(...)
   直接 fail-closed——行为正确,但报错看不出是"权限前置条件不满足",容易被当成别的故障。

用户侧临时解法(官方方案出来前)

icacls "<工作区>" /setintegritylevel (OI)(CI)Medium /T /C /Q   # 幂等,几十秒
# 注意:会话还活着时这只是止血,下一次授权会重打

或让 agent 直接用 --danger-full-access(不写标签)。

我们当时的误诊路径(供后来人少走弯路)

pip 缓存损坏 → 镜像不通 → 杀软/EDR → 系统时间 → 本地代理 → 全部不对。
真实顺序是三层,同一机制在不同前提下的三种出口:

1. 卷根缺 CREATOR OWNER → grantWrite 的 SetNamedSecurityInfoW 失败(Win32 5),沙箱起不来;
2. 标签打上后 → venv 进程被降级,tempfile 回退项目根,"装依赖失败/垃圾堆根目录";
3. 同一标签 → 工作区里未签名 exe 被 SmartScreen 拦,"突然弹无法识别的应用"。

[FalseLeonLai]

跟我的差不多
#7912

[FalseLeonLai]

合并?

[seaking-ai]

我也遇到了这个问题，折腾了一天

[dsh-community-assistant[bot]]

已收到这条反馈。