Windows: workspace-write 沙箱的常驻 Low 完整性标签，使工作区脚本在 DSH 外无法运行（“未对文件进行数字签名” / 资源管理器安全警告）

[appllove]

环境

• OS：Windows 10 Home 22H2，build 19045.7807，64-bit
• DSH：@deepseek-ai/dsh 0.2.1-rc.2（npm dist-tags 当前 next；latest=0.2.0-rc.2、alpha=0.2.1-alpha.5，即已是最新 next）
• Profile：web（dsh web，http://127.0.0.1:3080）
• 沙箱后端：@deepseek-ai/dsh-sandbox-windows-acl
• 复现工作区：C:\Users\ZHQ\Desktop\dshweb（另有 4 个 DSH 登记过的工作区同样复现）

摘要

DSH 在 Windows 上以 workspace-write 模式首次供给工作区时，会按设计（见仓库 agent note
.agents/notes/implemented/feature/2026-09-19-windows-acl-mandatory-integrity-confinement.zh.md）
给工作区根目录写入一条可继承、持久的强制完整性标签：

Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

（SID S-1-16-4096，SYSTEM_MANDATORY_LABEL_NO_WRITE_UP）。该标签被工作区内所有文件和子目录继承，
并且在会话结束、切换到 danger-full-access、甚至完全关闭 DSH、重启系统之后仍然存在。

副作用：Windows 会把带 Low 标签的脚本/可执行内容视为不可信，于是：

• 资源管理器双击工作区里的 .ps1/.cmd → 弹出「打开文件 - 安全警告 / 无法验证发布者」；
• PowerShell 5.1（LocalMachine=RemoteSigned）→ 报
  无法加载文件 ... 未对文件 ... 进行数字签名。无法在当前系统上运行该脚本。
  （PSSecurityException / UnauthorizedAccess）。

用户只能手工执行 icacls <工作区> /setintegritylevel Medium /T 才能恢复；
DSH 自带的 diagnose-windows-sandbox-acl 技能在 README 中明确说明“诊断保留完整性标签”，
无法修复“Low 标签的可执行文件影响用户在 DSH 外启动程序”的问题。

复现步骤

1. Windows 上启动 DSH（web profile），新会话默认权限预设为 workspace-write；
2. 打开任意工作区（例如 C:\Users\ZHQ\Desktop\dshweb），让 agent 执行任意命令（触发首次 ACL/标签供给）；
3. 在该工作区放一个 .ps1（或使用已有脚本），然后在 DSH 之外：
   • 资源管理器双击脚本 → 「打开文件 - 安全警告」；
   • 或 powershell -NoProfile -ExecutionPolicy RemoteSigned -File .\x.ps1 → 报“未对文件进行数字签名”；
4. 查看标签：

   icacls "<工作区>\x.ps1"      # Mandatory Label\Low Mandatory Level:(I)(NW)
   icacls "<工作区>"            # ...Low Mandatory Level:(OI)(CI)(NW)

5. 切换到 danger-full-access、停止 DSH、重启系统后标签仍在；手工恢复后脚本才可运行。

对照实验（排除误判）：

• 同一个 .ps1 复制到无标签目录 → 在 RemoteSigned 下正常执行；
• 对该文件执行 icacls /setintegritylevel Low → 立刻变成“未对文件进行数字签名”；
• 再执行 /setintegritylevel Medium → 恢复正常。

说明问题来自完整性标签，而非文件内容、签名或执行策略配置。

期望行为

• DSH 停止 / 切到 danger-full-access / 会话结束后，工作区恢复普通（Medium）标签；或
• 提供内置的显式恢复入口（命令 / GUI / 诊断技能）来移除或复原标签；或
• 至少在用户选择 workspace-write 时明确提示该副作用与恢复方法。

实际行为

• 标签常驻（设计 note 明确：按会话回收会带来整树传播的确定性成本，因此选择常驻）；
• 无内置正常恢复路径（诊断技能只保留标签；包 README「已知限制」承认无法修复该问题）；
• 报错信息（“未对文件进行数字签名”）与真实原因（沙箱完整性标签）无关联，用户很难定位，容易误判为文件损坏/病毒；
• 对“用户在自己电脑上运行自己写的脚本”造成实质影响，且跨会话、跨 DSH 生命周期持久。

影响

• DSH 处理过的目录里所有 .ps1/.cmd 在资源管理器双击或 PowerShell RemoteSigned 下都会被 Windows 拒绝；
• 重启后仍然存在，容易误判为文件损坏 / 被安全软件拦截，可能引发删除/重装等无效操作；
• 对把 DSH 用于脚本目录、工具目录、项目目录的日常使用影响明显。

建议修复方向（按优先级）

1. 提供内置恢复入口：例如 dsh sandbox unlabel <workspace>（或 GUI「清理工作区完整性标签」），
   内部调用 icacls /setintegritylevel Medium /T 或等价 Win32 API；诊断技能增加可选的“修复标签”。
2. 可选的清理时机：在 dispose() / 会话结束 / 切到 danger-full-access 时提供显式 opt-in 的标签回收
   （设计 note 指出按会话回收成本高，可作为可选 cleanup 而非默认）。
3. UI 提示：Windows 上选择 workspace-write 时说明“会在工作区留下 Low 完整性标签，可能影响在 DSH 外运行脚本”，
   并提供恢复方法。
4. 文档与诊断：README / 排障文档补充恢复命令；dsh status 或日志检测到工作区带 Low 标签时给出提示。
5. 诊断技能支持修复该标签（当前明确不修）。

临时规避（用户侧，已在本机验证）

• 把默认权限预设改为 danger-full-access（~/.dsh/profiles/web/cordis.patch.yml 的 defaultPreset，
  或 GUI 设置中的权限默认值）——不再启用该沙箱，也就不会打标签；
• 或保留 workspace-write，但定期运行一个维护脚本：读取 %USERPROFILE%\.dsh\storages\workspace.json
  登记的工作区，检测 Mandatory Label\Low 并递归恢复为 Medium（无需管理员权限）；
• 或把脚本放到工作区之外的目录运行（新文件继承外部目录的 Medium 标签）。

[argszero]

Your control experiment — one file, three label states, /setintegritylevel alone flipping the result — is what makes this actionable instead of a guess, so I checked every claim against the source. First: packages/sandbox/sandbox-windows-acl is byte-identical between d1b9c04067 (0.2.1-rc.2, your build) and 687f282e86 (master), so every line below applies to the version you are running.

Three parts of the report need adjusting. The remove path you conclude does not exist does exist in the module; what is missing is a front door onto it, and the repository already records that as undecided work. Your icacls recovery is correct for one half of the state — and it leaves workspace-write unable to write until the next provision. And the bundled diagnostic is not blind to the label: it reads it and prints it, it just has no operation that removes it.

1. The module can remove the label; only the revocable half is wired to it

revokeWrite (acl.ts:431) removes the capability ACE and decides the label's fate from the same read:

mergeAndApply(
  api, path, buildExplicitAccess(sidPtr, abi.REVOKE_ACCESS, 0), oldAcl,
  hasForeignGrant(oldAcl, sidPtr) ? { kind: 'keep' } : { kind: 'clear' },
  descriptor, 'revokeWrite',
)

(acl.ts:443.) hasForeignGrant (:337) answers "does any other capability grant still stand on this DACL", and { kind: 'clear' } reaches SetNamedSecurityInfoW as LABEL_SECURITY_INFORMATION with a null SACL (:257-258) — the label is removed, not skipped. The design note you cite states the rule in the same words: revokeWrite clears it only when no other capability grant remains on the directory (.agents/notes/implemented/feature/2026-09-19-windows-acl-mandatory-integrity-confinement.md:21).

It is reachable through the public class: add(path, standing = false) (grant.ts:105) puts a path in revocablePaths, and dispose() (:115) revokes those and only those. The workspace half passes standing = true on purpose (index.ts:34-37) — the same decision your citation points at — and the package README documents both halves at :62 and :66.

So ask #1 is not "provide a restore entry": the mechanism exists one layer down, documented and tested. What does not exist is a command, a menu item or a diagnostic operation that calls it on the standing workspace half. The repository names that gap itself — README.md:184 lists a future cleanup command may reap the standing ACEs, and :204 ends a cleanup command that reaps standing workspace ACEs from renamed workspaces is undecided. Your report is the strongest evidence yet that this deferred item has a real user cost, and your priority list matches the shape of the work.

2. Your icacls recipe fixes the label, and only the label

icacls cannot revoke the capability ACEs at all: that SID is derived per grant (workspace-sid.ts), so naming it fails with ERROR_NONE_MAPPED (1332). The package README says exactly that at :128. The label is the opposite case — it names S-1-16-4096, a well-known SID — which is why your recipe works and is the only half a user can fix without an ACL API call.

Two boundaries worth stating if you publish the recipe:

• The label is what admits the sandbox. README.md:129: without it the confined child cannot write at all. So immediately after /setintegritylevel Medium /T the state is the worst of both: the standing capability ACE is still there, and no Low label lets the Low-integrity child through. Until the next workspace-write provision re-labels, that workspace is read-only to the agent. Treat the command as "make my scripts runnable now", not "clean the workspace".
• /T re-labels objects that exist; it does not restore an unlabelled state. Every file and directory ends up carrying an explicit Medium label, which is not the same as never having been labelled — relevant to your step 5 ("重启后仍然存在") and to any comparison you make against a never-provisioned directory.

3. The recovery does not stick, which is why ask #2 is the interesting one

grantWrite skips its apply only when three things stand at once: the exact capability ACE, the world FILE_DELETE_CHILD deny, and the exact Low label (acl.ts:386-388). An explicit Medium label breaks the third, so the next provisioning takes the full merge path and re-applies the label over the whole tree — the cost the code names as eager inheritance; minutes on large workspaces (:365-366).

That also settles the shape of an opt-in cleanup. dispose() could revoke the workspace grant (standing = false) and your ask #2 would work for one session; the next one pays the re-propagation, and your note's own reasoning (:21) adds the second half — it would race with concurrent sessions. A default of standing plus a per-workspace opt-out is therefore the only formulation that does not reintroduce the cost per session; a per-session toggle is not.

Incidentally, the cost is quoted two ways in-tree: README.md:365 says minutes on large workspaces, the design note (:27) says tens of seconds on large workspaces. Since ask #2 turns on that number, unifying it is worth doing.

4. Inheritance stops at objects created after provisioning

Your summary says the label is inherited by all files and subdirectories. It is inherited by everything created after the grant: buildLowLabelAcl (acl.ts:169) writes an inheritable (OI)(CI) ACE, and inheritance by definition reaches later children. Subdirectories that already existed keep their own label and are not touched — a separate report covers exactly that symptom (#9903). Practical consequence for the maintenance script you describe: a single non-recursive check on the root will miss untouched pre-existing subtrees, and those are precisely where "some scripts run, some do not" shows up.

5. The diagnostic reads the label — it just cannot change it

assets/diagnose-windows-sandbox-acl/scripts/diagnose-windows-sandbox-acl.ps1 shells out to icacls and matches S-1-16-4096 or the English Low Mandatory Level (:456-464), then prints LOW_LABEL= per path in its inspect_acl observation (:559). Every repair it offers is DACL-side (:190-191 writes DACL only), which is why it preserves the label — the README's wording means "the repair does not touch the SACL", not "the tool cannot see it".

The defect in that half is narrower and more fixable than ask #5 implies: LowLabel starts as $null (:416) and is only ever set to $true (:464), so "no label", "the SACL was unreadable", and "a localized rendering we did not recognize" all print the same value. Making that field tri-state (present / absent / unknown) plus one removal operation would close both halves of your ask.

6. Your documentation complaint is correct

WRITE_OWNER — the prerequisite that decides whether the label write can succeed at all — appears outside the package only in internal design notes (.agents/notes/**) and a test fixture; git grep WRITE_OWNER hits nothing under docs/ or website/. The troubleshooting material a user reaches in the failing moment does not carry it.

One measured resource, since you built the comparison experiment: argszero/cordis-plugin-sandbox-grant-advisor (source on GitHub; its npm publication is currently blocked by a registry outage on my side) collects the Windows sandbox measurement set, and its README carries a user-measured full-state removal recipe — ACL backup, icacls /remove:d Everyone, a derived-SID pass through the ACL API, then /setintegritylevel M /T over 85,613 objects with zero failures. That recipe is quoted from its author, not verified here; I have no Windows host in this environment.

[appllove]

Thanks — the review kept me from filing a wrong diagnosis, so here is the payback: I tried to close the two
questions your comment left open. Short version: one of my earlier claims was wrong, and the "standing label"
decision is better justified than I said — but the user-facing problem is still real, and there is a cheap way
to expose a fix.

Method

new AclSandbox({ writableDirs: [ws], tempDir, writeSid: workspaceWriteSid(ws),
                 tempWriteSid: tempWriteSid(tempDir), mode: 'workspace-write' })

init() / dispose() are the real provisioning path; labels were read back with icacls. For "clear", I used
SetNamedSecurityInfoW(path, SE_FILE_OBJECT, LABEL_SECURITY_INFORMATION /* 0x10 */, NULL, NULL, NULL, NULL, NULL)
(Sacl = NULL), which is what revokeWrite's kind: "clear" branch does.

Correction first: inheritance does reach pre-existing children

I previously suggested the label only affects objects created after it is applied. That is wrong. On a root with
no label, one init() labels the entire existing tree:

state	root	pre-existing child\	pre-existing child\grand\	file created later
after first init()	Low (OI)(CI)	Low (I)(OI)(CI)	Low (I)(OI)(CI)	inherits Low

So #9903's unlabelled pre-existing subdirectories are not explained by inheritance being forward-only.
What actually blocks re-labelling is an explicit label already sitting on the child:

Case A — after the common repair, re-provisioning re-labels the root only

1. init() → whole tree Low (inherited, (I) present);
2. icacls <root> /setintegritylevel Medium /T /C /Q → every object now carries an explicit Medium label,
   Medium Mandatory Level:(NW) — note the (I) is gone;
3. init() again → root only becomes Low … (OI)(CI)(NW); child, child\grand, child\a.ps1 stay
   explicit Medium.

That is the reproducible "does not self-heal" state, and it is the sequence a user is most likely to hit
(repair, then reopen the workspace). For a confined Low token, Medium descendants are exactly the
Access to the path … is denied case in #9903 — arrived at from the opposite direction.

Case B — clearing is whole-tree, and it is not cheap, so your cost argument holds

step (10,200 objects: 100 dirs × 100 files + nesting)	measured
first init() (apply label)	14.7 s
one SetNamedSecurityInfoW clearing the root's label	13.7 s, and every descendant loses its inherited label with it
revokeWrite's clear path via the module	15.1 s, same result
init() again after a complete clear	13.2 s, whole tree re-labelled

So wiping and re-applying cost the same order of magnitude, both roughly a full tree walk. The design note's
reasoning is sound — per-session revoke would pay that walk twice per session, and I would not ask you to make
it the default.

One nuance worth knowing: clearing performed per object (as opposed to clearing the root) leaves those
objects in a state where a later inheritance pass does not re-label them, while a root-only clear does.
That asymmetry is what makes "repair then re-provision" produce a permanently half-labelled tree, and it is
probably worth pinning in acl.spec.ts.

Case C — the /T junction hazard, measured precisely

icacls /T did cross a junction, but not the way a flat reading suggests. Workspace A had A\link →
junction to B, both fully Low, then A only:

icacls A /setintegritylevel Medium /T /C /Q
→ Successfully processed 8 files; Failed processing 0 files

A                    Medium        (was Low)
A\sub, A\sub\deep    Medium        (was Low)
A\sub\a.ps1          Medium        (was Low)
B                    Low  ← unchanged
B\outside1.ps1       Medium  ← changed, outside the workspace
B\sub2               Medium  ← changed
B\sub2\outside2.ps1  Medium  ← changed

So the traversal writes labels to the junction target's contents but leaves the target directory entry
alone — which makes it very easy to miss when eyeballing icacls output. That is consistent with the
1,576 / 31,718 numbers in #9903. My repair now walks per object, skips reparse points and runtime directories,
and I verified the property directly: with the same fixture, the junction target's contents stayed Low.

Naive traversal also descended into node_modules / .venv, which on this host turned a 14 s job into minutes
of churn over objects that will never be executed as scripts.

What I would actually ask for

Given Case B, the "standing label" is defensible — but the exit is still missing, and that is the part users
cannot work around:

1. A user-facing unlabel command (dsh sandbox unlabel <workspace>, or a GUI action) that clears the
   workspace root's label. Case B says one call plus a tree walk does it, and it is exactly the operation a
   user needs after DSH has visited a directory they also use outside DSH. It does not have to change any
   session semantics — re-entering workspace-write re-labels as Case B step 4 shows.
2. Say what to expect when the two states meet. Per Case A, "repaired workspace + workspace-write" is a
   silently half-labelled tree. Documenting that (or detecting it) is cheaper than any behavior change, and it
   is the part that costs a user a day today.
3. Mention the side effect where users look. The word "label" appears in no troubleshooting page a user
   reaches in the failing moment; the only trace is internal design notes. One line next to the
   workspace-write choice — "this marks the workspace Low integrity, which can make your own scripts refuse to
   run outside DSH; dsh sandbox unlabel clears it" — would have saved me an hour of chasing Mark-of-the-Web
   and antivirus.

Offering

If useful I can post the exact probe as a script: it builds the fixture, runs the three states, asserts on
parsed icacls output, and deletes its own workspace. It would drop straight into acl.spec.ts as a
regression for Case A (the explicit-label-blocks-inheritance asymmetry), and it needs no Windows version newer
than the one already in CI.