[Windows sandbox] workspace-write child process dies with 0xC0000142 (STATUS_DLL_INIT_FAILED)

[cmz333]

Windows ACL sandbox: workspace-write child dies with 0xC0000142 (STATUS_DLL_INIT_FAILED)
TL;DR
@deepseek-ai/dsh-sandbox-windows-acl gives the restricted token a default DACL that
grants full access to the write capability SID (S-1-4-x-y), a SID that exists only in
the token's restricting list and is absent from the token's normal groups. Any object the
child creates with that default DACL therefore fails the child's own pass-1 access check, so
early DLL initialization dies with STATUS_DLL_INIT_FAILED (0xC0000142). read-only is
unaffected because it grants Everyone (which is in the normal groups). One-line fix:
always use Everyone for the token default DACL.
Environment
OS: Windows 11 Pro, build 10.0.26200
Harness: @deepseek-ai/dsh 0.2.0-rc.2 (bundled in DSH Desktop 0.11.1)
Profile: web (DSH_PROFILE=web), hosted by the Electron desktop app
Sandbox mode: workspace-write (the deployment default)
Symptom
Every confined shell command fails: the pwsh/bash executor wraps the command with the
windows-acl runner, the restricted child exits 3221225794 (= 0xC0000142,
STATUS_DLL_INIT_FAILED) with no output, and the tool must escalate to
danger-full-access for every call.
Reproduction
Run the shipped runner directly (on the Desktop app use ELECTRON_RUN_AS_NODE=1 with the
Electron binary as node, since the asar is not plain-node readable):

node <app.asar>/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js \
  --workspace <dir> --temp <tmp> --mode read-only      -- cmd /c echo OK   # exit 0
node <app.asar>/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js \
  --workspace <dir> --temp <tmp> --mode workspace-write -- cmd /c echo OK  # exit 3221225794

Root cause (verified by isolation)
Using the public AclSandbox API (all workspace-write, manageDacls off to avoid ACL edits):
token default DACL restricting list exit code
Everyone logon + Everyone (+cap SID) 0
Everyone logon + Everyone 0
cap SID logon + Everyone + Everyone 0xC0000142
cap SID logon + Everyone + cap SID 0xC0000142
The failure tracks the token default DACL exactly, not the restricting list, not the
directory ACL grants, and not the private temp directory. S-1-4 in the restricting list
is fine; the crash happens only when S-1-4 (or any SID absent from the token's normal
groups) is merged into the token default DACL.
AclSandbox.init() calls:

setTokenDefaultDaclGrant(api, restrictedToken,
  this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);

setTokenDefaultDaclGrant merges a full-access ACE for that SID into the token's inherited
default DACL. The chosen SID is the write capability SID, which is present only in the
WRITE_RESTRICTED restricting list — not in the token's normal groups. Objects the child
creates with this default DACL are therefore unreachable by the child's own pass-1 check,
breaking the loader's early object setup. read-only picks worldSid (Everyone), which is
in the normal groups, so it works.
Proposed fix

1. packages/sandbox/sandbox-windows-acl/src/index.ts
   Always grant Everyone in the token default DACL (identical to the already-working
   read-only path). The workspace write allowlist is enforced by the WRITE_RESTRICTED
   restricting SIDs plus the capability ACE on the workspace DACL; the token default DACL only
   governs objects the child newly creates.

-    setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);
+    setTokenDefaultDaclGrant(api, restrictedToken, worldSid);

2. packages/sandbox/sandbox-local/src/index.ts
defaultProbeWindowsAcl probes --mode read-only only, and on Windows the ACL runner is the
   sole candidate and is therefore never probed at all — a broken workspace-write backend is
   silently selected instead of surfacing as SANDBOX_UNAVAILABLE. Probe the mode that is
   actually used (workspace-write) on a disposable temp directory so a regression like this
   fails loud and fails closed.
   Impact
   Every user on Windows Desktop running the default workspace-write preset cannot run any
   confined shell command (per-call escalation workaround only).
   The workspace directory has already been modified persistently by the sandbox
   (Everyone (CI)(DENY)(DC), a capability-SID grant, and a Low mandatory label), which is
   by-design standing state and is not revoked by dispose().

[R3Dzf]

The isolation results make a strong case for the token's default DACL being the issue, rather than the workspace ACLs themselves.

I'd agree with separating the two responsibilities: the default DACL needs to let the child access objects it creates, while the restricted-token SIDs and workspace ACLs determine which filesystem locations it can write to.

One thing I'd add to the proposed fix is a regression test that checks both functionality and confinement:

1. Launch a simple child command in workspace-write mode and verify it succeeds.
2. Create and read a file inside the allowed workspace.
3. Attempt to create a file outside the allowed workspace and verify access is denied.
4. Repeat the basic launch test in read-only mode.

That last pair matters because fixing the startup failure alone wouldn't demonstrate that the sandbox still enforces its intended restrictions.

I'd also make the availability probe exercise the selected mode, as suggested, so this fails before a real command is dispatched rather than forcing users into repeated permission escalations.

[cmz333]

Thanks for the review — I agree on both points. On the separation: yes. The token's default DACL only needs to let the child reach the objects it creates itself; the restricting SIDs and the workspace ACLs are what actually bound where it can write. That's the shape the fix takes — the default-DACL grant goes back to Everyone (matching the already-working read-only path), and the write allowlist is left entirely to the restricting SIDs plus the capability ACE on the workspace DACL. On the regression test: added, and it covers functionality and confinement together: workspace-write: launch a trivial child → exits 0 workspace-write: write and read back a file inside the allowed workspace workspace-write: attempt to write outside the allowed workspace → denied read-only: launch a trivial child → exits 0 Checks 3 and 4 are the ones that keep the fix honest — a passing launch on its own would not show that the write allowlist is still enforced. All four pass on the patched build. I also folded in the probe change you suggested: defaultProbeWindowsAcl now exercises workspace-write (the mode that is actually dispatched) instead of read-only, so a regression surfaces as SANDBOX_UNAVAILABLE before any real command is sent, rather than as a per-call escalation loop. Full write-up, the isolation evidence, and the runnable test are in discussion #9507.

[R3Dzf]

Nice, that covers both the launch failure and the sandbox restrictions. Glad the probe change worked out too. Thanks for checking all four cases!

[kirlyr]

This is a useful isolation of the problem, especially the comparison between read-only and workspace-write with manageDacls disabled.

One detail I think is worth evaluating before settling on worldSid as the final fix is whether the session's logonSid can be used as the default-DACL trustee instead.

The important requirement seems to be that the selected SID must satisfy both access checks:

• The normal token group check.
• The WRITE_RESTRICTED restricting SID check.

A capability SID that only exists in the restricting list cannot satisfy both checks on its own.

Everyone works as a candidate based on the reported reproductions, but the logon SID may provide a narrower session-scoped alternative, assuming it is enabled in the token and included in the restricting list.

I'd suggest including regression coverage for:

1. read-only child process startup.
2. workspace-write child process startup.
3. File creation inside the allowed workspace.
4. Write attempts outside the allowed workspace being denied.
5. Child process creation involving inherited or newly created handles.
6. The sandbox availability probe using the actual selected mode.

The last case is particularly important. A successful read-only probe should not be treated as proof that workspace-write is usable.

This doesn't replace the proposed fix, but it could help verify that the DACL change restores process startup without accidentally broadening workspace write permissions.

I haven't reproduced the failure locally, so I'm treating this as an additional verification suggestion rather than a confirmed alternative patch.

[cmz333]

Tested it — you were right. I swapped the default-DACL trustee from Everyone;to the session's logonSid;and reran the regression suite: all four checks still pass (workspace-write launch, write+read inside the workspace, write outside denied, read-only launch), and the write allowlist is unchanged. logonSid;is the narrower choice — it's in both the token's normal groups and the restricting list, so it satisfies both access checks without widening the default DACL to the whole machine. Report updated to use it, with credit. Thanks!