[Bug Report] windows-acl: Low integrity label (and allow ACE) not applied to existing subfolders, so the confined child can write only the workspace root

[mrink68]

Version: @deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2, Windows 11 Pro (26200), NTFS, workspace on a non-system drive.

What happens

In a workspace-write session on an existing project (a git repo with many folders), every write below the workspace root is denied, while a write at the root succeeds:

Set-Content <workspace>\root-probe.txt          → OK
Set-Content <workspace>\src\.probe              → Access to the path … is denied.
Set-Content <workspace>\docs\.probe             → Access to the path … is denied.
Set-Content <workspace>\.git\.probe             → Access to the path … is denied.

The same subfolder write, run outside the sandbox, succeeds. Giving the user full control on the subfolders ((OI)(CI)(F), verified) does not change the result.

Cause

After the sandbox has initialised, the workspace root carries the label and the capability ACE, but folders that already existed do not:

icacls <workspace>
    Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
    S-1-4-…:(OI)(CI)(…write…)          (explicit)

icacls <workspace>\docs
    (no mandatory label → implicit Medium)
    (no S-1-4-… ACE)

The confined child runs at Low integrity, so the no-write-up policy denies it in every folder still at implicit Medium, whatever the DACL allows. Folders created after init inherit the label, which is probably why a test in a fresh, empty workspace passes.

One more observation: when something later rewrites a subfolder's DACL (for example icacls /grant), Windows recomputes that folder's inherited ACEs and the S-1-4-… ACE appears there. The integrity label still does not, and the write stays denied. So the label is the blocking part.

Related: #8209 describes the same Low-subject / Medium-object denial for git's key store outside the workspace. This report is about the workspace itself.

Expected

In workspace-write, the confined child can write anywhere under the workspace, including folders that existed before the session started.

Suggested fix

Apply the label and the ACE so that they reach existing children. For example, use SetNamedSecurityInfoW with LABEL_SECURITY_INFORMATION (and the DACL) in a way that propagates to existing objects, or TreeSetNamedSecurityInfoW, or equivalently icacls <ws> /setintegritylevel (OI)(CI)low /T. Large trees (build outputs, node_modules) make a full walk slow. Doing it once per workspace, or documenting the cost, would help.

Repro

1. Create C:\tmp\ws\sub\ (the folder exists before the session).
2. Start a sandboxed session with C:\tmp\ws as its workspace, workspace-write.
3. From the confined child, write C:\tmp\ws\a.txt → works. Write C:\tmp\ws\sub\a.txt → access denied.
4. icacls C:\tmp\ws shows Low Mandatory Level:(OI)(CI)(NW). icacls C:\tmp\ws\sub shows no label.

[argszero]

Confirmed at the source level — and it is sharper than a missing (OI)(CI): the repository documents the opposite of what you measured, and the test suite has never exercised a child that already existed.

1. The documented claim your measurement contradicts. packages/sandbox/sandbox-windows-acl/README.md (§ Known Limitations) states: "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)", and grantWrite's own doc comment in src/acl.ts repeats it ("the SetNamedSecurityInfoW apply, which would otherwise re-propagate the identical descriptor across the whole tree (eager inheritance; minutes on large workspaces)"). Your icacls output shows a pre-existing child holding neither the capability ACE nor the label — so the eager walk does not happen for descendants that already exist.

2. Why the suite never caught it — your guess is right, and it is provable. The only inheritance assertion in the package (tests/acl.spec.ts, "the ambient-delete deny inherits to subdirectories only, never onto files") calls grantWrite(api, dir, …) first and mkdirSync(childDir) after it. Every child in that suite is created after the apply, so the only mechanism the tests ever exercise is creation-time auto-inheritance. No test under sandbox-windows-acl/tests creates a child before grantWrite.

3. What the call can and cannot do. SetNamedSecurityInfoW writes the descriptor of the named object; it does not push a changed inheritable ACE into descendants that already exist — which is why the platform ships TreeSetNamedSecurityInfo, and why icacls needs /T. Read that way, everything you observed follows: the root gets the ACE and the label, pre-existing descendants get nothing, and the inherited ACE appearing only after something rewrites that child's DACL is the recomputation a DACL write performs on the object being written — which leaves the SACL untouched, so the label still does not appear. That is exactly your "the label is the blocking part", and your experiment is what establishes it: an ACE granting your account full control cannot help either way, because the confined child's token is write-restricted to its logon SID + Everyone + the two capability SIDs, so it never consults your account's ACE. Note also that your first probe already had the answer: granting (OI)(CI)(F) to the user "did not change the result" is expected by design, not evidence — the DACL rewrite it forced is what made the capability ACE visible afterwards.

4. The second path, and why it is permanent. The grant is materialized once per provider lifetime per workspace (sandbox-local/src/index.ts, materializeAclGrant → AclWriteGrant.add(workspaceRoot, true)), and grantWrite returns early when the root already carries the exact ACE + deny + label (src/acl.ts, hasExactGrant/hasExactDeny/hasExactLabel). So once the root is satisfied, a later session on the same workspace re-applies nothing and the descendants are never revisited. Your fresh-workspace case exercises the propagation half; the short-circuit is what keeps the hole open across restarts.

5. Your fix direction matches the platform primitives, with one note from this side: the cost you flag is real, and it is the reason the exact-ACE skip exists — but that skip keys on the root only, so a descendant-aware propagation has to be tracked separately, or the same short-circuit that makes re-provisioning cheap will keep skipping the subtree. And the label is only half: the capability ACE has to reach the child too.

6. Your temporary remedy, recorded as a quotation rather than a verification (we have no Windows host): icacls <ws> /setintegritylevel (OI)(CI)low /T. One boundary belongs beside it — icacls cannot name the derived capability SID (ERROR_NONE_MAPPED, Win32 1332), so the ACE half can only be re-materialized through the ACL API, and your own observation is the cheap way to force that half: any DACL write on the child recomputes its inherited ACEs.

7. Where the fix belongs. This is core (sandbox-windows-acl); a plugin cannot repair it. What a plugin can do is name the mechanism before the user spends the time you spent on DACL grants. @argszero/cordis-plugin-sandbox-grant-advisor already recognizes the in-workspace denial shape (sandbox: { mode: 'workspace-write', denied: true } plus an in-workspace path in the command). I am folding your root-versus-descendant split into it, with the check your report supplies: icacls <root> carries Mandatory Label\Low … and the S-1-4-… ACE, icacls <root>\<sub> carries neither. npm: https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor

Thanks for the repro and the before/after pair — the icacls output on both objects is what makes this decidable rather than guessable.

[argszero]

The plugin that carries the analysis above is published — closing the loop on that reply.

@argszero/cordis-plugin-sandbox-grant-advisor 0.22.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor

One-line usage: install it and mount its bundle patch in your profile.

npm install @argszero/cordis-plugin-sandbox-grant-advisor

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

What this release takes from the report above, and how it is stated in the advice:

• The shape measured here becomes a fourth breadth entry. The family already forked on breadth, and this shape lands inside the second of them ("nothing below the root is writable, the root itself still writable"). That breadth covers two shapes, and the advisory now says so: the child may carry the capability ACE with no Mandatory Label line, or it may carry neither — no ACE and no label — in which case the whole security-descriptor write missed it rather than one half of it. Breadth is the first cut and not the last: whenever the root itself still writes, the text sends the reader to one icacls read of a child instead of letting the breadth decide.
• The false repair is recorded as one. Rewriting a child's own DACL makes Windows recompute its inherited ACEs, so the missing capability ACE then appears while the write stays denied. A reader who runs it would see a grant that is present and a denial that persists — the two readings the advice now separates.
• Your relabel is quoted as yours. icacls "<root>" /setintegritylevel (OI)(CI)Low /T is attributed to this report and is not offered as the plugin's remedy — this project has no Windows host to verify a line on. Three boundaries travel with it: it relabels the whole tree including objects that were never denied; it cannot name the derived capability SID (ERROR_NONE_MAPPED 1332, a ceiling that extends to the removal direction as well); and afterwards the tree is writable by every Low-integrity process on the machine, not only this session's.
• One narrowing the plugin adds. The family's account is that the grant, written on the root, failed to reach something below it — so a denial naming the root itself is declined rather than explained that way, because that is the standing-grant branch and a different fact.

The advisory is attached to the denial in the same step (a user-role notice via additionalContexts, once per agent), and the plugin never edits an ACL, never elevates, and never offers a wider sandbox mode as a fix.