[BUG] Workspace-write 沙箱缺陷：受限进程可通过工作区内的目录 Junction 删除工作区外文件

[CaoJasonChang]

在 Windows 上，DeepSeek Harness（@deepseek-ai/dsh 0.1.5-rc.2）的 @deepseek-ai/dsh-sandbox-windows-acl 在 sandbox: workspace-write 模式下：
受限进程可在工作区内自行创建指向区外任意目录的 directory junction，再经该 junction 删除区外已有文件。

案例
在 〈工作区根〉 内创建 junction probe-j，指向工作区外的 〈区外目录〉。
删除路径：〈工作区根〉\probe-j\某文件（该路径解析到 〈区外目录〉\某文件）。
删除成功；随后区外该文件不存在。
同一 junction 下：新建文件、向已有文件追加写入 → 均被拒绝。
该案例曾误用真实资源文件作靶，造成一次实际损坏。

推测原理
workspace-write 会对工作区授予 capability SID 的 Modify 级权限（实现中含 DELETE、FILE_DELETE_CHILD 等）。在工作区内创建 junction 属于对可写目录的写入，故被允许。
Windows 删除文件通常需：对文件有 DELETE，或对父目录有 FILE_DELETE_CHILD。经 〈工作区〉\某junction\某文件 访问时：
创建 / 覆写：更可能按最终目标文件做 ACL 校验 → 区外无写权限 → 拒绝。
删除：更可能（或至少在效果上）用到了工作区侧 junction 目录上已继承的 FILE_DELETE_CHILD，从而删掉目标命名空间中的文件 → 放行。
因此表现为「能删不能写」：写入边界整体有效，删除路径与创建路径的鉴权不一致，形成仅限删除的逃逸。

[argszero]

Thank you for the report. The asymmetry you measured — create/append refused, delete allowed — is not a side detail: it is the fingerprint of the one route the design already knows about, and it points at one specific line in the grant.

Read at 00102833df (dsh-v0.1.7-alpha.2). I have no Windows host, so everything below is source-level; §3 gives one precondition to check and the two experiments that would settle what I could not run.

1. Your guess is right in shape, with one correction: the authority is the capability SID, not the ambient one

packages/sandbox/sandbox-windows-acl/src/win32-abi.ts:22,28:

export const FILE_DELETE_CHILD = 0x0040
export const GRANT_MASK = (FILE_GENERIC_WRITE | DELETE | FILE_DELETE_CHILD) & ~STANDARD_RIGHTS_WRITE

The workspace grant gives the capability SID FILE_DELETE_CHILD explicitly — the docstring at :23-27 reads "Capability-SID access mask granting write, delete, and child deletion" — and that ACE is merged with the default container+object inheritance (src/acl.ts:51 SUB_CONTAINERS_AND_OBJECTS_INHERIT = 0x3, applied at :409). So the directory you created inside the workspace:

• inherits GRANT_MASK, i.e. the confined token holds FILE_DELETE_CHILD on the junction directory itself;
• inherits the Low mandatory label written by the same SetNamedSecurityInfoW call (acl.ts:377-413).

The same grant also writes a world deny for that same right (acl.ts:408: buildExplicitAccess(worldSidPtr, DENY_ACCESS, FILE_DELETE_CHILD, CONTAINER_INHERIT_ACE)). That deny removes the ambient route — the one PerryLink describes in #7298 — and it cannot remove the capability's own copy, because that copy is the allow-list mechanism: removing it would take in-workspace deletes with it (tests/runner.spec.ts:142 pins that Remove-Item and Rename-Item both succeed inside a granted workspace).

So <workspace>\probe-j\victim is deleted by a right the named parent carries, and the mandatory no-write-up check is satisfied because that same directory is labeled Low. Creation and append are different: they must pass the restricting-SID pass-2 intersection against the resolved target, which never received the capability ACE — and FILE_DELETE_CHILD is exactly the right that intersection does not co-sign, as the package README states at README.md:90.

2. This is the same shape as the three delete-confinement commits — and it is the case they assume away

.agents/notes/implemented/feature/2026-09-19-windows-acl-mandatory-integrity-confinement.md:19 states the fix's load-bearing property:

The label is what reaches the parent-FILE_DELETE_CHILD route at all: the kernel evaluates the mandatory policy inside the access check whichever right supplied the authority, so a Medium object outside the granted roots is delete-proof as well as write-proof.

Read that over the directory whose right supplies the authority: a junction created inside the workspace is such a directory, and it is inside the root, carrying both the Low label and the capability ACE. An alias does not have to defeat either edit — it only has to be the object those edits landed on. The same note's decision list (:16) says the deny makes "the capability ACE's DELETE bit the only delete authority inside a granted root", while GRANT_MASK grants the capability a second delete authority (the parent right, 0x40). Inside one directory the two are indistinguishable; an alias is what separates them.

The series each closed one route of the same shape: d5ad3baeb5 (label reaches "whichever right supplied the authority"), 36e632751e (world deny / "DELETE bit is the only delete authority"), 3d5ba3b83f (deny narrowed to containers). All three read "the parent directory" as the object's real parent. Nothing in the package handles reparse points: reparse|junction occurs zero times under packages/sandbox/, and README.md:112-125 (Verified boundaries) lists Everyone keep-alive, hard links, AppContainer ACLs, FAT volumes and wide directories — no aliases — even though the same package already resolves aliases for its own disjointness checks (src/path-boundary.ts:12-14 uses realpathSync.native, against the non-resolving resolve at src/index.ts:186).

3. One precondition, two experiments I could not run

C0 — check the target's label first. icacls <outside dir> (and the file): if that tree shows no Mandatory Label line (i.e. Medium), the reading above is the only one that fits, because the label layer is what denies the ambient route and a Low target would pass it. If it is Low-labeled, the authority story changes and the experiment below is the way to tell.

E1 — attribute the authority (this decides which fix applies). Remove the outside ambient route while leaving the workspace-side route untouched:

mkdir C:\dsh-out
icacls C:\dsh-out /deny "$env:USERNAME:(DC)"

Then recreate the junction, and delete a file in C:\dsh-out whose own DACL grants the user no DELETE. Success ⇒ the authority came from the workspace-side parent (the junction), as I read it. Failure ⇒ it came from the outside directory's ambient ACL, and my reading is wrong.

E2 — is it delete-only? The grant propagates eagerly through the tree (README.md:177, "walks every descendant immediately"). Does that walk descend into a reparse point that was already present at provisioning time?

mkdir C:\ws2
mklink /J C:\ws2\j C:\outside2
icacls C:\outside2      # before: expect no capability SID, no Low label
# provision a workspace-write session whose workspace is C:\ws2
icacls C:\outside2      # after: capability SID? Low label?

If the outside tree gains the ACE and the label, the boundary is not delete-only there but a write escape for that subtree, which is the more urgent half. I could not decide from the source whether the inheritance walk follows a mount point.

4. Where a fix can go (maintainers' call, not mine)

• Drop 0x40 from GRANT_MASK — delete authority would then have to come from the object's own inherited DELETE (which the same ACE already grants to objects inside the root), the mask would match the documented invariant, and under the reading above the junction route closes because the junction's deny already removes the world's copy of the parent right. The unknown is tests/runner.spec.ts:142, whose single probe asserts Remove-Item and Rename-Item succeed "(DELETE + FILE_DELETE_CHILD)": a rename plausibly needs the parent right, so the test should be split into delete-only and rename-only before this trade can be judged. I could not run it — no Windows host, and this checkout has no node_modules.
• Refuse the alias: fail loudly at provisioning when the workspace tree already contains a reparse point resolving outside the grant root. Closes E2's precondition and the pre-existing-alias case; does not stop a junction the child creates itself.
• Detect: a post-run sweep for reparse points leaving the root. Cheapest, but it runs after the damage, and a delete does not come back.
• Not available here: there is no ACL right that separates "create a directory" from "make it a reparse point" — junctions need no privilege (unlike symlinks, which want SeCreateSymbolicLinkPrivilege), so creation cannot be refused through this mechanism.

5. Interim and residue

• read-only carries no write SID, so no capability ACE and no 0x40 exist anywhere — it is immune. That is a mode change, not a fix, and your case needed writes.
• Residue: Get-ChildItem -Force -Attributes ReparsePoint -Recurse <workspace> (or dir /al). Worth stating next to your damage note: removing a junction removes the link, not its target.
• If you can share the junction's creation command, the outside target directory's path, and whether both sat on one volume, C0 and E1 become a one-shot confirmation rather than a survey.

Cross-reference: #7298 is the same family, and PerryLink's reply there reduces it to one question — was the deleted link's parent inside the granted tree? Your case is outside by construction, so it needs none of the three facts that question was waiting on.

[argszero]

Correction, and it is the most useful part: I read HEAD (00102833df) and your report is against 0.1.5-rc.2. Those two trees differ at exactly the layer under discussion, so my previous comment described a grant your build did not have.

$ git tag --contains 36e632751e     # "deny the ambient parent-delete right inside granted roots"
dsh-v0.1.7-alpha.1
dsh-v0.1.7-alpha.2
$ git tag --contains d5ad3baeb5     # "confine Windows deletes with a Low integrity label"
dsh-v0.1.7-alpha.1
dsh-v0.1.7-alpha.2
$ git log -1 --format='%h %cd' dsh-v0.1.5-rc.2
fb2c4b9e69 Thu Sep 10 21:50:19 2026 +0800

At your tag the grant was one entry, with no deny and no label:

$ git show dsh-v0.1.5-rc.2:packages/sandbox/sandbox-windows-acl/src/acl.ts
231  export function grantWrite(api: Win32Bindings, path: string, sidPtr: NativePtr): void {
242      mergeAndApply(api, path, buildExplicitAccess(sidPtr, abi.GRANT_ACCESS, abi.GRANT_MASK), oldAcl, descriptor, 'grantWrite')

(GRANT_MASK already carried FILE_DELETE_CHILD there — that tag's win32-abi.ts:28 — but grep for DENY_ACCESS / MANDATORY in that tag's acl.ts and token.ts returns nothing: no world deny, no Low integrity lowering.)

On that build your asymmetry needs no further explanation, because HEAD's README names the route in so many words:

The write-SID intersection covers only the object's OWN access check: Windows can also authorize a write or a delete from the parent directory's FILE_DELETE_CHILD right, which no restricting SID has to co-sign …

Write outside → needs the restricting-SID pass-2 co-sign, which no outside directory carries → refused. Delete outside → authorized by your ambient rights on the object's own parent, which nothing in that build intersected and nothing denied → succeeds. Note what that means for the junction: the ambient route is path-independent, so it needs no junction to be reachable — and no junction can change its outcome either. Read that way, the junction is how you demonstrated the escape, not what produced it.

So my earlier §1 ("the authority is the capability SID, not the ambient one") should be read as a claim about HEAD, not about your build: it assumed the deny and the label already stood. Which parent the kernel actually evaluates FILE_DELETE_CHILD on — the junction's own descriptor or the one it resolves to — is the one thing I still cannot settle from source, and E1 in that comment is exactly the measurement that separates the two readings. I should have led with the version gap instead.

What this leaves open, in order of what I would spend effort on:

1. Retest on 0.1.7-alpha.1+ — this is the whole next step. At HEAD the workspace root is labeled Low with OI|CI and the token is lowered to match, and the kernel's mandatory check refuses write-class access (which includes delete) from a Low token to any object that is not itself Low. That is the layer written after your build, and it is the one that should stop precisely your delete. Whether it does is the finding, and it costs one run.
2. A junction that already exists when the workspace is provisioned is the case I genuinely cannot decide from source, and it is the one where a junction could still matter at HEAD. SetNamedSecurityInfoW with inheritable ACEs "walks every descendant immediately" (README, Grant materialization) — does that walk descend through a reparse point and stamp the capability ACE and the Low label onto the outside tree? If it does, that subtree becomes writable as well as deletable and it is a live escape on the fixed build; if it does not, a junction can only ever name objects the label layer still refuses. Worth knowing which, independent of your report.
3. Was the target on a non-NTFS volume? The README files that corner as untested: a FAT-class target outside the granted roots "stores no security descriptor; its effective integrity label is assigned by the system rather than recorded on the object, so the label layer's behavior there is untested". If your target sat on such a volume, hypothesis 1 above does not apply to it and this is a separate open case on HEAD.

My earlier C0/E1 still apply; on HEAD they now sit behind the version question. If you can say which volume the target was on and whether the junction existed before or during the session, items 2 and 3 become decidable without any DSH internals.

[argszero]

A plugin for this shape is now published, so the thread is not left without a mountable answer.

@argszero/cordis-plugin-reparse-escape-guard — npm: https://www.npmjs.com/package/@argszero/cordis-plugin-reparse-escape-guard · source: https://github.com/argszero/cordis-plugin-reparse-escape-guard (MIT, 0.1.1)

- insert:
    - id: reparse-escape-guard
      name: '@argszero/cordis-plugin-reparse-escape-guard'

It mounts on the public tools/pre-execute waterfall and, for each call, canonicalizes the tool's declared path operands and compares them against the same derivation the fence uses — writableRoots(policy) from the @deepseek-ai/dsh-sandbox package root, via ctx.sandboxPolicy.resolve({ session }), the same service call tool-fs makes. If an operand reads as inside a writable root and resolves outside every one, the call is refused before dispatch, naming the three facts the fence cannot:

Error: refused by reparse-escape-guard: this path operand of "write" reads as
inside the write area and resolves outside it.

"/ws/link/out.txt"
  as written:              /private/var/…/ws/link/out.txt  (inside /private/var/…/ws)
  actually resolves to:    /private/etc/out.txt  (outside every writable root)
  the link:                /private/var/…/ws/link

The second line is the part that is genuinely absent upstream, and it is not a string prefix test: the walk stops where the path first enters a writable root and re-appends the remaining components untouched. That is what makes link/../x correct (a lexical collapse says it is contained; the kernel follows the link out and never comes back), and what makes a root with two spellings correct (on darwin /var resolves to /private/var, so only one of the two writings begins with the canonical root text writableRoots() derives).

Reads are deliberately not judged — no enforcement dialect restricts reads, and writableRoots() is consulted on mutation paths alone — so a read through an alias stays legal.

What it does not do, stated plainly, because this thread is about a deletion through a junction performed by a shell command:

• The guard judges the path operands a tool declares in its arguments (write's file_path, edit's file_path, str_replace_editor's path on mutating commands). A path reached by a shell command line is not an operand and is invisible to it by default. There is a shellFields opt-in that scans declared text for path-looking words, but that is a best-effort net over tokens, not a guarantee — it cannot know that Remove-Item deletes and Get-Item does not, and it will miss a path built at runtime.
• It does not replace enforcement. The fence still re-canonicalizes at the moment of publication; this only refuses the call earlier and explains it. Under read-only there are no writable roots and the plugin is inert by construction.
• It cannot make an approved write succeed: action: ask routes the crossing to the approval flow, and the honest limitation there is the one already established upstream — the harness cannot widen the policy on the strength of an approval, only an escalation grant can, so deny is the default and the message points at sandbox_permissions where the tool advertises it.

On this thread's own mechanism: the report is against 0.1.5-rc.2, and the delete-confinement series (d5ad3baeb5 → 36e632751e → 3d5ba3b83f) is contained only in dsh-v0.1.7-alpha.1 and later, so a retest on that line is the thing that would tell us whether the DELETE / FILE_DELETE_CHILD asymmetry still reproduces. Either way the guard is what turns a refusal into a sentence the model can act on, instead of a retry with a different name.

37 tests run against a real Cordis context, a real ToolRuntime, a real tools/pre-execute waterfall and a real SandboxPolicyService, with an unmounted control arm showing the same call dispatched when nothing guards it; one suite is an integration test against the real @deepseek-ai/dsh-fs-sandbox, showing the fence and the guard agree on the verdict and differ only in diagnosis. mutations.py breaks each claim in the built output and requires the suite to go red (11/11 killed).

One note for anyone mounting it, because it is the kind of thing that only shows up after the release: this package's own 0.1.0 shipped a files field naming the entry point and not its siblings, so it installed and then died on its first sibling import. The packaging suite now reads npm's own pack list rather than trusting the manifest's intent, and asserts that the shipped set covers the entry's whole module graph — it was confirmed red on the 0.1.0 manifest, naming the four withheld modules, before the fix. 0.1.0 is deprecated on npm; use 0.1.1.

[CaoJasonChang]

按讨论中的 C0、E1、E2，在 Windows 上对 0.1.5-rc.2 和 0.1.7-alpha.1 做了测试。
全部测试里，区外靶标都没有被删除，E2 也没有在区外目录上新增 SID 或 Low 标签；区别在于：0.1.5-rc.2 能在会话中建成 junction，0.1.7-alpha.1 不能。
下面是核对到的结果。
dsh-junction-submission.zip

环境

• Windows 11 专业工作站版，版本 10.0.26200，构建 26200
• 最初六次测试的工作区与区外目录都放在 C: 上的测试目录中，文件系统 NTFS，同一卷
• 执行账户记为 operator，这是一个脱敏账户，不是实际账户
• PowerShell 5.1.26100.6725，Node v24.18.1
• 许可模式为 workspace-write（DSH_PERMISSION_MODE=workspace-write，dsh --profile headless --dump-config 的输出含 workspace-write）
• 0.1.5-rc.2 使用本机已有安装；0.1.7-alpha.1 由操作者安装到独立前缀。被测进程没有安装或切换版本
• 每次测试使用独立的工作区和区外目录。junction 命令为 cmd /c mklink /J <工作区>\probe-j <区外目录>
• 区外目录在 headless 之前的 icacls 输出中没有 Mandatory Label 行
• 删除是否发生以父进程 Test-Path 为准

0.1.7-alpha.1 在启动 headless 之前，工作区目录上增加了一条不继承的 operator:(F)。未加这条 ACE 时，开通返回 SetNamedSecurityInfoW failed (Win32 5)。

各测试在做什么

• baseline：沙箱进程在会话中执行 mklink /J，然后经 junction 新建、追加、删除，并按区外真实路径直接删除另一个靶标
• E1：会话前对区外目录执行 icacls /deny operator:(DC)，对两个删除靶标执行 icacls /deny operator:(D)，其余与 baseline 相同
• E2：会话前由操作者执行 mklink /J。headless 前后各保存一份区外目录的 icacls。提示词要求沙箱进程不要创建或拆除 junction

最初六次测试

版本	测试	junction 时机	结束后 junction	新建文件	经 junction 的删除靶标	直接删除靶标
0.1.5-rc.2	baseline	会话中	存在	不存在	仍在	仍在
0.1.5-rc.2	E1	会话中	存在	不存在	仍在	仍在
0.1.5-rc.2	E2	会话前	存在	不存在	仍在	仍在
0.1.7-alpha.1	baseline	会话中	不存在	不存在	仍在	仍在
0.1.7-alpha.1	E1	会话中	不存在	不存在	仍在	仍在
0.1.7-alpha.1	E2	会话前	存在	不存在	仍在	仍在

0.1.5-rc.2 的 baseline 与 E1 中，mklink /J 的输出含 Junction created。随后的新建、追加、经 junction 删除和直接删除，stderr 含 Access to the path ... is denied.，记录中同时出现 [sandbox: file access denied under workspace-write mode]。

0.1.7-alpha.1 的 baseline 与 E1 中，会话内的 mklink /J 输出含 Access is denied.，结束后 junction 不存在。直接删除区外靶标的 stderr 含 Access to the path ... is denied.，记录中同时出现上述 sandbox 行。

两版 E2 的区外目录，开通后的 icacls 与开通前相比没有新增 SID，也没有 Low Mandatory Level 行。没有生成写逃逸停止记录。

测试中未使用 FAT 卷。

补充记录

用与 0.1.7-alpha.1 相同的前缀方式另装一份 0.1.5-rc.2，在新目录上再跑 baseline、E1、E2。记录到的结果与上表中本机已有的 0.1.5-rc.2 三次测试相同。

此后按三套安装各跑 baseline、E1、E2，并更换目录后再跑全部6+3个测试。三轮用的都是新建子目录：

• 工作区为 C:\dsh-lab 下的新目录，靶子为桌面上新建文件夹中的新目录。该靶子目录继承账户的 (OI)(CI)(F)，与工作区同在 C: 卷
• 工作区为 C:\dsh-lab 下的新目录，靶子为 D:\dsh-test 下的新目录。D: 为另一块本地 NTFS 卷，这些靶子目录继承 Authenticated Users 的 (M)。会话前的 mklink /J 可以从 C: 上的工作区目录指向 D: 上的靶子目录
• 工作区和靶子都是桌面上另一个新建文件夹里的新目录，两边都继承账户的 (OI)(CI)(F)

这三轮里，两套 0.1.5-rc.2 的会话中 junction 均存在，新建文件不存在，删除靶标仍在。0.1.7-alpha.1 的会话中 junction 不存在，删除靶标仍在；其 E2 的会话前 junction 存在。各轮 E2 开通后，区外目录的 icacls 没有新增 SID，也没有 Low Mandatory Level 行。