[0.2.0-rc.2][Windows] workspace-write: subdirectories unwritable — Low mandatory label not inherited by children (DACL grant present)

[ZHrZH97]

Windows workspace-write sandbox: workspace subdirectories are unwritable (Low mandatory label is not applied to / inherited by children)

Package: @deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2
Platform: Windows 11 (build 26200 family), NTFS
Severity: High — under workspace-write the workspace is effectively unusable: only files directly under the workspace root can be written; every subdirectory is denied.
Class: Behavior contradicts the package README / missing mandatory-integrity-label coverage

---

1. Summary

Under workspace-write, a confined child process (Low integrity) cannot write to any subdirectory of the workspace, while writing to the workspace root itself works normally.

The DACL is not the cause: the capability SID's write grant is present and correctly inherited at every level. The problem is that the mandatory integrity label is applied only to the workspace root and never reaches the subdirectories — not even a subdirectory created after the grant was materialized. Those directories therefore keep the system-default Medium integrity level, and the kernel's mandatory-integrity check (no-write-up) denies a Low-integrity process write access to a Medium object. This happens independently of, and before, the DACL check, so the seemingly correct write grant in the DACL is never exercised.

The package README describes this label as the workspace's "inheritable label" and describes grant materialization as an "eager full-tree propagation". The observed behavior contradicts both statements.

---

2. Minimal reproduction (user's perspective, no source reading required)

1. Set the DSH file policy to workspace-write (the default mode).
2. Prepare a subdirectory inside the workspace, e.g. C:\workspace\output.
3. Perform any write from the confined session:

Set-Content -LiteralPath 'C:\workspace\output\probe.txt' -Value 'ok'

Actual result:

write C:\workspace\output\probe.txt    -> Access to the path ... is denied
write C:\workspace\scripts\probe.txt   -> Access to the path ... is denied
write C:\workspace\probe.txt           -> succeeds

The root is writable; subdirectories are not. The same denial reproduces identically at the .NET layer ([System.IO.File]::WriteAllText is denied the same way), so this is not a PowerShell-level artifact. Switching the policy to full access immediately restores every write, confirming the denial comes from the restricted-token path rather than from the directory's own permissions.

---

3. Evidence

3.1 The confined child runs at Low integrity

> whoami /groups
Mandatory Label\Low Mandatory Level    Label    S-1-16-4096

3.2 The mandatory integrity label exists only on the workspace root

> icacls "C:\workspace"
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

> icacls "C:\workspace\scripts"     -> no mandatory label ACE found
> icacls "C:\workspace\output"      -> no mandatory label ACE found
> icacls "C:\workspace\downloads"   -> no mandatory label ACE found
> icacls "C:\workspace\backups"     -> no mandatory label ACE found

The label carries (OI)(CI) (object inherit + container inherit) and should therefore cover the whole subtree; in practice it exists only on the root.

3.3 Decisive control: a freshly created child inherits the DACL grant but not the label

Creating a brand-new subdirectory after the grant has been materialized isolates the two mechanisms cleanly:

> mkdir C:\workspace\output\__label-test        (created from an unconfined session)

> icacls C:\workspace\output\__label-test  |  (filtered for "Mandatory Label")
(no output — no mandatory label ACE)

> icacls C:\workspace\output\__label-test
S-1-4-<a>-<b>:(I)(OI)(CI)(W,D,DC)          <-- capability ACE: (I) = inherited, works
BUILTIN\Administrators:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
BUILTIN\Users:(I)(RX)

The freshly created child does inherit the capability ACE from the workspace root's DACL (marked (I)), so DACL inheritance works. It does not receive the Low integrity label, even though that label is also configured (OI)(CI) on the root. Both inheritable entries are declared on the same object in the same apply call, yet only one propagates.

This rules out "the child simply predates the grant" and isolates the failure to the label layer.

3.4 The DACL side is entirely correct (proof that this is not an ACL problem)

The capability SID's grant is present on every subdirectory, with correct inheritance:

C:\workspace          S-1-4-<a>-<b>  Allow  DeleteSubdirectoriesAndFiles, Write, Delete, Synchronize  inherited=False
C:\workspace\scripts  S-1-4-<a>-<b>  Allow  DeleteSubdirectoriesAndFiles, Write, Delete, Synchronize  inherited=True
C:\workspace\output   S-1-4-<a>-<b>  Allow  DeleteSubdirectoriesAndFiles, Write, Delete, Synchronize  inherited=True

A full-tree scan found no anomalous write-class deny entries anywhere. Judged purely by the DACL, these directories should all be writable; the write is refused by the integrity check, not by the access control list.

---

4. Contradiction with the documentation

Three statements in the package's own README.md conflict directly with the measurements:

(a) README:129 — describes the label as inheritable and covering the tree:

the workspace's inheritable label survives the session (and same-volume moves), so any other process running at Low integrity as the same user … can write and delete inside the workspace, where a Medium label would have denied it.

(b) README:187 — describes grant materialization as propagating to all descendants:

Grant materialization is an eager full-tree propagation — SetNamedSecurityInfoW on a directory with inheritable ACEs walks every descendant immediately (tens of seconds on large workspace trees) …

(c) README:102 — and explicitly states that only labeled directories remain writable:

Both modes spawn a Low-integrity token, and only labeled directories stay writable for it.

Taken together, (a)–(c) imply that subdirectories must carry the label and are therefore writable. Measurement 3.2/3.3 shows they carry no label, so (a) and (b) do not hold as written.

The package's own diagnosis script independently reports the same contrast when inspecting the workspace root versus a subdirectory (LOW_LABEL=True for the root, empty for scripts), corroborating the icacls evidence.

---

5. Relevant source locations

File: lib/types-*.js (locally lib/types-Cl_DXjhk.js); line numbers for 0.2.0-rc.2.

Line	Symbol	Note
425	buildLowLabelAcl	builds the label ACL; line 436 addMandatoryAce(acl, 2, 3, 1, lowLabelSidPtr) with inheritance flag 3 = OI|CI (matching the (OI)(CI) observed on the root)
451	hasExactLabel	idempotency check requiring an exact label ACE match
592	grantWrite	the only place the label is applied (line 608 mergeAndApply(... labelEdit ...))
322	buildExplicitAccess	inheritance flags default to 3; grantWrite does not pass them explicitly, so it takes the default
833	restrictTokenIntegrity	lowers the child token to Low (SetTokenInformation(TokenIntegrityLevel)); its comment states a token left at Medium would ignore these labels
1291	restrictTokenIntegrity(api, restrictedToken, lowLabelSid)	call site
1278	for (const path of this.writableDirs) grantWrite(...)	grants only the entries of writableDirs
runner.js:144	writableDirs: parsed.mode === "workspace-write" ? [parsed.workspace] : []	writableDirs contains only the workspace root

Inferred cause (offered for maintainers, not verified layer by layer):

grantWrite runs only against the workspace root. Although the label ACE carries OI|CI, on this host it does not reach the subdirectories — not even one created after the grant — while the DACL capability ACE from the same apply call does inherit normally. The kernel evaluates its mandatory-integrity check against each object's own effective label, so an unlabeled subdirectory counts as system-default Medium and the Low child is denied by no-write-up. The likely explanation is that the inheritable flag on the mandatory-label entry is not honoured the way the DACL-side inheritance is; maintainers can tell whether that is a flag issue in addMandatoryAce, a property of applying the label through SetNamedSecurityInfoW, or host-specific.

Worth noting: the failure is independent of the DACL, so ACL-oriented diagnosis and repair cannot help. Confirmed empirically — manually adding an explicit FullControl grant for the current user on a subdirectory still left writes denied.

---

6. Impact

• Under workspace-write, no subdirectory is writable, so the agent cannot produce files in the usual places (output/, scripts/, src/, …). The default sandbox mode is effectively unusable for real projects.
• The failure surfaces as a bare Access to the path ... is denied, which does not point at the integrity level. It is very easily misdiagnosed as a file-permission problem, which costs substantial debugging time (as it did here).
• The behavior contradicts the README, leading users and maintainers to an incorrect expectation of the boundary.

---

7. Suggested directions

1. Ensure subdirectories actually receive the label. Verify why the mandatory-label entry's OI|CI inheritance does not materialize on children while the capability ACE's does, and make the label reach the subtree by whatever mechanism reliably works.
2. Or stop depending on the label. If label propagation cannot be relied on, writability should not rest on the premise that "only labeled directories stay writable".
3. Make the failure diagnosable. When the DACL permits the write but the integrity check refuses it, report a distinguishable error (e.g. "Low integrity cannot write to an object not labeled Low") instead of a bare access-denied.
4. Align the documentation. If "subdirectories are not writable" is a known or intended constraint, the README must say so explicitly; the current wording at README:129 leads readers to the opposite conclusion.

---

8. Reproduction material

A read-only script that prints each directory's mandatory integrity label via icacls is available on request.

Note: capturing a child process's output with spawn(..., { stdio: 'pipe' }) inside a confined session fails with EPERM, a boundary already documented at README:186 — so run such an evidence script outside a confined session.

[argszero]

Thank you — this is a careful report, and the source observations in §5 check out against master:

• buildLowLabelAcl builds the label ACE with SUB_CONTAINERS_AND_OBJECTS_INHERIT (packages/sandbox/sandbox-windows-acl/src/acl.ts:180-181), i.e. the (OI)(CI) you see on the root. Your reading of the flag is right.
• The grant and the label are applied only to the paths in writableDirs (src/index.ts:270-272), and under the runner that array is [workspace] alone (src/runner.ts:163). There is no descendant walk anywhere in the module, so nothing in it re-visits a child — whatever propagation you expected is left to the OS.

Where the permanence comes from — the part the measurements could only infer. grantWrite returns early when the root already carries the exact ACE, the exact world delete-child deny and the exact label; all three must match (src/acl.ts:386-388), and hasExactLabel reads only the directory it is handed, i.e. the root's own SACL (:198-204). So the first call labels the root, every later call sees "already labelled" and returns, and a child that missed the label is never looked at again — not later in the session, not in any later one. That is the same root-only short-circuit the DACL half has (hasExactGrant), which is what made the earlier report about stubborn subdirectories permanent. The comment on that shortcut states its purpose outright — to "skip the eager full-tree propagation" — so the design assumes the propagation happened, and no code path can notice when it did not.

What I cannot settle from here. Whether the cause is the (OI)(CI) flag on a mandatory ACE not being honored, the SACL half of the merged SetNamedSecurityInfoW not triggering auto-inherit onto existing children, or something specific to the 26200 family, needs a Windows host and a debugger. I have none, so I am not going to post a repair line I cannot verify — §7 items 3 and 4 (make the two refusals distinguishable; make the documentation match the behavior) are the changes that can actually be made here. Your §4(b) quote is precisely the sentence that makes this read as a defect in the apply rather than in the propagation: "eager full-tree propagation" describes what the module expects the OS to do, not something it implements.

Which half a reader is looking at — both halves produce this identical denial:

• a handful of stubborn objects while the rest of the tree writes normally → the DACL half: the capability ACE did not arrive at those objects;
• nothing below the root writable at all, with the root itself the only writable place → the label half, as here.

Only a direct child of the labelled root is evidence for the second: a grandchild having no label proves nothing, because inheritance is per-parent and the intermediate directory carries none. Your §3.3 control is exactly the direct-child form, which is what makes it decisive.

A stopgap for the shape, if not for the cause. Your reproduction is a denied write inside the workspace, and the executors' denial dialect for this backend includes access to the path — the comment there names your pwsh/.NET message verbatim (packages/sandbox/sandbox-local/src/index.ts:211-213) — so such a result is stamped sandbox: { mode: "workspace-write", denied: true }. @argszero/cordis-plugin-sandbox-grant-advisor 0.13.0 (published today) reads that stamp and attaches a durable user-role advisory covering this branch: that retrying is provably useless, the breadth fork above, the permanence mechanism, and the diagnose-windows-sandbox-acl / LOW_LABEL (S-1-16-4096) check that separates the halves from outside a session. It repairs nothing, prints no repair command for the reason given above, and stays silent unless the host is Windows, the stamped mode is workspace-write, and every absolute path the command named lies inside the workspace.

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'