Windows ACL sandbox: native children with piped stdio silently never run; 0xC0000142 hard-error dialog

[baiwei89]

Target repo: deepseek-ai/deepseek-harness
Version: @deepseek-ai/dsh@0.1.7-rc.2
Profile: web, session file policy workspace-write
Affected packages: @deepseek-ai/dsh-sandbox-windows-acl, @deepseek-ai/dsh-win32-process, @deepseek-ai/dsh-subprocess-local

Environment

• Windows 10 Pro 19045, x64
• Session runs as the built-in Administrator, elevated (Mandatory Label\High Mandatory Level), UAC EnableLUA=1, ConsentPromptBehaviorAdmin=0
• This OS image is debloated: Windows Defender is not installed (no MsMpEng.exe, no WinDefend service, Defender PowerShell module absent), no third-party AV/EDR registered in SecurityCenter2, and WerSvc was Stopped/Disabled before testing
• Confined children reach the sandbox through dsh-subprocess-local/lib/runner.js (visible in the process tree as node.exe .../runner.js -- C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ...)

Symptom 1 鈥?native children whose stdio PowerShell has to pipe never run, silently

Inside any sandboxed tool call, PowerShell-mediated capture or redirection of a native command's output makes that
child never run: no output, $LASTEXITCODE stays unset, the redirect target stays empty, and nothing is logged anywhere
(no exit event in Win32_ProcessStopTrace, no WER record, no Application-log entry).

Measured matrix (all on the same host, same session, same binaries):

Command form	Result
node -e "console.log('ok')" (output straight to stdout)	鉁?exit 0, output present
1..3 | ForEach-Object { ... } (cmdlet-only pipeline)	鉁?works (anonymous pipes carry a restricting-SID ACE, as documented)
cmd /c "node -e ""..."" > file" (cmd opens the file itself)	鉁?works, file has content
$o = node -e "..."	鉂?silent, $LASTEXITCODE unset
node -e "..." > file	鉂?silent, file empty
node -e "..." 2>&1	鉂?silent
cmd /c "..." 2>&1	鉂?silent 鈥?the whole cmd never runs
cmd /c "echo hi | findstr hi"	鉂?exit 1, stderr: Not enough memory resources are available to process this command

8 rounds 脳 3 child launches (a node.exe, a launcher .exe, and a CLI's bundled node.exe) with the capture form:
24/24 silent failures, each returning in 68鈥?42 ms; the same binaries succeed when output is not captured.

The unifying rule we can infer: PowerShell pipes the output of native commands even for a plain > file redirect
(it copies the child's piped output to the file itself, unlike cmd, which hands the file handle to the child). Whenever
such a pipe must be created for a confined grandchild, the child never runs 鈥?matching the documented boundary:

Piped stdio capture is impossible for confined grandchildren 鈥?libuv's pipe stdio uses named pipes, whose client-end
open requests write access no restricting SID is granted (the Win32 layer's default SD template, not the token default DACL),
so spawn(..., { stdio: 'pipe' }) inside a confined process fails with EPERM 鈥?> 鈥?dsh-sandbox-windows-acl/README.md (Boundaries)

Impact (the serious part): a command that never ran is indistinguishable from a command that succeeded with no output.
An agent that verifies work by running a check and reading its output concludes "nothing to report" while the check never
executed. In our session this produced several wrong intermediate conclusions before it was caught, and the empty
$LASTEXITCODE / empty redirect target are the only clues.

Symptom 2 鈥?node.exe - 搴旂敤绋嬪簭閿欒 hard-error dialog, code 0xC0000142

A Windows hard-error box titled node.exe - 搴旂敤绋嬪簭閿欒 ("搴旂敤绋嬪簭鏃犳硶姝ｅ父鍚姩 (0xc0000142)") appears occasionally.
Attribution is impossible from the box: it is owned and rendered by csrss.exe, not by the failing process
(confirmed: the window's owning PID was csrss.exe, whose start time equals boot time). With WerSvc disabled on this
image, no WER/Application-log record existed at all.

This also matches the documented boundary:

Console isolation is unavailable 鈥?children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL
initialization with STATUS_DLL_INIT_FAILED (0xC0000142) 鈥?> 鈥?dsh-sandbox-windows-acl/README.md (Boundaries)

鈥?the keep-alive group (logon SID + Everyone) is present in both modes: without it, early DLL initialization dies with
0xC0000142 鈥?> 鈥?same file, "Modes and token lists"

The popup appeared twice during otherwise ordinary confined spawn activity (including once exactly while a batch of four
captured-stdio commands silently failed).

Ruled out during diagnosis

• Antivirus: no Defender at all, no third-party AV/EDR registered, zero detection records.
• NTFS/permission misconfiguration: read/execute are not intersected by the restricting SIDs; ACLs are correct.
• Missing token privileges: SeAssignPrimaryToken / SeIncreaseQuota are present but Disabled in the elevated token,
  yet the overwhelming majority of confined spawns succeed, so the CreateProcessAsUserW path itself works.
• Multiple server instances competing for the port: a single listener was verified.

Suggested directions

1. The root of Symptom 1 looks like the restricted token's default DACL: the README states anonymous pipes work
   because that default DACL carries a full-access restricting-SID ACE, while named pipes fall back to the Win32
   default SD template and are therefore denied. Extending the token default DACL to cover the pipe case used by
   CreateProcessAsUserW/libuv (or passing an explicit pipe SD that carries the restricting SIDs) should make
   PowerShell-mediated redirection work for confined grandchildren.
2. Make the failure loud. Today a native child that cannot be launched yields empty output with $LASTEXITCODE
   unset 鈥?an agent reads that as success-with-no-output. Surfacing windows-acl-run: <detail> / a spawn error, or a
   non-zero exit code, would remove the most dangerous property of this bug.
3. Audit Windows spawn sites for CREATE_NO_WINDOW / CREATE_NEW_CONSOLE / windowsHide under the restricted token
   (Symptom 2). dsh-win32-process deliberately avoids those flags (STARTF_USESHOWWINDOW + SW_HIDE), so the
   remaining call site is elsewhere in the subprocess seam; dsh-subprocess-local starts its Job runner with
   windowsHide: true, which is worth checking first.
4. Consider exposing a policy knob that disables console isolation explicitly, documenting the DLL-init tradeoff.

WER is now enabled on this host (WerSvc was disabled by the OS image's debloat script, which is why nothing was logged
at first), and the exit-code / dialog watchers are ready to re-run 鈥?happy to instrument a specific build.