[BUG] (maybe) DSH Windows ACL sandbox: two defects make workspace-write unusable

[ZenLiuCN]

DSH Windows ACL sandbox: two defects make workspace-write unusable

Environment

• DSH 0.2.0-rc.2, Windows 10/11 x64
• Backend chain: @deepseek-ai/dsh-sandbox-windows-acl → dsh-sandbox → dsh-bash-sandbox → dsh-tool-bash
• Shell: busybox-w32 (the shipped bash.exe is a byte copy of busybox.exe)
• Reproduced on more than one machine and more than one account (standard user and built-in Administrator)
• read-only works. workspace-write does not. danger-full-access works.

Impact

Every bash command under workspace-write fails with exit code 3221225794
(0xC0000142) and no output, so the Bash tool is completely unusable in the default
mutating mode on Windows.

---

Defect 1 — sandboxed children die in conhost.exe (0xC0000142)

Symptom

$ echo sandbox-probe
(no output)
[exit code: 3221225794]        # 0xC0000142 STATUS_DLL_INIT_FAILED

ProcMon evidence

The child's own image and DLLs load fine:

bash.exe  9972  Load Image  <install>\bash.exe                 SUCCESS
bash.exe  9972  Load Image  C:\Windows\System32\ntdll.dll      SUCCESS
bash.exe  9972  Load Image  C:\Windows\System32\kernel32.dll   SUCCESS
bash.exe  9972  Load Image  C:\Windows\System32\KernelBase.dll SUCCESS

Then it tries to allocate a console, and the console host dies inside the restricted token:

bash.exe    9972  Process Create  C:\Windows\system32\conhost.exe  SUCCESS  PID: 12072
conhost.exe 12072 Process Start   Parent PID: 9972                 SUCCESS
conhost.exe 12072 Load Image      C:\Windows\System32\conhost.exe  SUCCESS
conhost.exe 12072 Load Image      C:\Windows\System32\ntdll.dll    SUCCESS
conhost.exe 12072 Process Exit    Exit Status: -1073741790   # 0xC0000022 ACCESS_DENIED
bash.exe    9972  Thread Exit     Thread ID: 5856
bash.exe    9972  Process Exit    Exit Status: -1073741502   # 0xC0000142

conhost.exe never even reaches kernel32.dll. ProcMon logs no ACCESS DENIED for the
child itself; the denial is inside the console host.

Root cause

dsh-win32-process spawns restricted-token children through spawnInheritedJobProcess()
with:

createRestrictedProcess(api, options, commandLine, 4, startupInfo, processInfo)
//                                                 ^ creationFlags = CREATE_SUSPENDED only

There is no DETACHED_PROCESS and no CREATE_NO_WINDOW.

The Electron entry binary is IMAGE_SUBSYSTEM_WINDOWS_GUI. A console-subsystem child of a
process with no console makes the Windows loader call AllocConsole() at process start.
That allocates a console inside the sandboxed token, which cannot host conhost.exe, so
AllocConsole fails and the loader reports 0xC0000142 before any user code runs.

Because the runner is GUI-subsystem it never inherits the launching console, so this fires
on every sandboxed spawn, not just some.

Why this is easy to miss when testing outside DSH

A standalone repro that spawns the same restricted token from powershell.exe always
succeeds: powershell.exe has a console, the child inherits it, and conhost.exe is
therefore never created. The bug only appears when the parent has no console.

Fix

Make the entry binary console-subsystem so the whole process tree inherits a console:

<install>\DeepSeek Harness.exe
  e_lfanew  = DWORD @ 0x3C
  Subsystem = WORD  @ e_lfanew + 92
  02 00 (WINDOWS_GUI)  ->  03 00 (WINDOWS_CUI)

and launch DSH from a console. Confirmed: after this, direct children and their fork()
descendants run normally, with app.asar left completely stock.

Equivalent alternative (asar patch): add DETACHED_PROCESS to the restricted-token spawn
flags. That fixes only the direct child — busybox's own fork() children still allocate a
console and still die with 0xC0000142 — so the subsystem fix is strictly better.

---

Defect 2 — CreatePipe fails under the workspace-write token

Once the console problem is fixed, workspace-write still cannot use pipes:

$ echo a | cat
bash: line 0: can't create pipe: Bad file descriptor
[exit code: 2]

$ x=$(echo hi)
bash: line 0: can't create pipe: Permission denied

Both are the same failure seen with different errno. Nested shells fail identically
(bash -c 'echo x | cat' from inside the sandbox), so this is not a CRT fd-table or
lpReserved2 issue — under this token, processes at any depth fail to create a pipe.

A direct Win32 probe under the sandboxed token gives the precise error:

CreatePipe  FAILED  err=5        # ERROR_ACCESS_DENIED

It is object creation that fails, not pipe I/O. read-only mode works
(echo a | cat → a; printf 'p\nq\n' | wc -l → 2), so this is not a platform
limitation.

Evidence — the sandbox token's default DACL

=== TokenDefaultDacl ===
  aceCount = 4
  [0] type=0x00 mask=0x001F01FF sid=S-1-4-<a>-<b>-1   <- temp cap SID, real FILE_ALL_ACCESS
  [1] type=0x00 mask=0x10000000 sid=S-1-5-32-544      <- Administrators, GENERIC_ALL
  [2] type=0x00 mask=0x10000000 sid=S-1-5-18          <- SYSTEM, GENERIC_ALL
  [3] type=0x00 mask=0xA0000000 sid=S-1-5-5-0-<sid>   <- logon, GENERIC_READ|GENERIC_EXECUTE

=== TokenRestrictedSids ===
  count = 4
  [0] attr=0x7 sid=S-1-5-5-0-<sid>          <- logon
  [1] attr=0x7 sid=S-1-1-0                  <- Everyone
  [2] attr=0x7 sid=S-1-4-<c>-<d>            <- workspace cap SID
  [3] attr=0x7 sid=S-1-4-<a>-<b>-1          <- temp cap SID

The logon SID is session-specific and the two S-1-4-* capability SIDs are derived from a
hash of the workspace path; both are redacted here.

Note that Everyone (S-1-1-0) is not in the default DACL, and neither is the user SID.

Root cause

New objects created without an explicit security descriptor take their DACL from the token's
default DACL. For a WRITE_RESTRICTED token the object manager requires both passes of
the access check:

• pass 1 (enabled groups: user, Administrators, Everyone, logon, …)
• pass 2 (restricting SIDs: logon, Everyone, workspace cap SID, temp cap SID)

In the DACL above the only ACE with a real, object-specific mask is [0], and its
trustee S-1-4-* exists only in the restricting list, never in the enabled groups.
ACEs [1] and [2] carry GENERIC_ALL (0x10000000) and [3] carries 0xA0000000
(GENERIC_READ|GENERIC_EXECUTE); those are generic bits that do not map to
file/pipe-specific rights, so they grant nothing for a pipe object. Pass 1 therefore fails
and creation is refused with ERROR_ACCESS_DENIED.

read-only works because createRestrictedToken() calls

setTokenDefaultDaclGrant(api, token, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)

and in read-only the fallback worldSid (Everyone) is used, merging a real
Everyone:FILE_ALL_ACCESS ACE. Everyone is simultaneously an enabled group (pass 1 ✓)
and a restricting SID (pass 2 ✓), so the object is usable. In workspace-write the cap SID
replaces it and neither pass succeeds on its own.

Fix

In workspace-write, merge a SID that the token actually has enabled — Everyone, the
logon SID, or the user SID — into the default DACL in addition to the cap SID. Concretely,
call setTokenDefaultDaclGrant for worldSid as well as tempWriteSidPtr ?? writeSidPtr,
so newly created pipes and other unnamed objects satisfy both passes.

Why files are unaffected but pipes are not

Files created inside the workspace inherit the workspace directory's inheritable ACEs (DSH
sets those explicitly, including Everyone), so pass 1 succeeds. Pipes have no parent
directory and must rely on the token default DACL, which is why they are the visible
casualty.

---

Reproduction

1. read-only mode: everything works.
2. workspace-write mode with a stock app.asar: 0xC0000142, no output (Defect 1).
3. Flip the entry binary's PE Subsystem to 03 00 and relaunch from a console: simple
   commands and fork() applets work, pipes still fail (Defect 2).
4. Dump the sandbox token's TokenDefaultDacl, then call CreatePipe under that token: it
   returns err=5.

Defect 2 can be isolated without a full run. Build a token with
flags = 0xD | WRITE_RESTRICTED and the four restricting SIDs listed above, impersonate it,
and call CreatePipe while varying only what gets merged into the default DACL:

default DACL += cap SID only        -> CreatePipe FAILED err=5   (reproduces)
default DACL += cap SID + Everyone  -> CreatePipe OK
default DACL += Everyone only       -> CreatePipe OK

[ZenLiuCN]

[wzwjustdoit]

Defect 3 — workspace-write also lowers the restricted token to Low integrity, which kills every MSYS2 program

First, thanks — the AllocConsole analysis in Defect 1 explains a symptom I had been
misattributing to the token default DACL, and it matches what I observed independently
(exit code 3221225794, no output, GUI-subsystem parent).

This is a third, orthogonal defect. It involves neither AllocConsole nor
CreatePipe, and it is not covered by Defect 1 or 2.

Environment

• DSH 0.2.0-rc.2, Windows x64, desktop form, workspace-write
• Shell from the dsh-plugin-git-bash community plugin (Git for Windows MSYS2
  bash.exe 5.3.15) rather than the shipped busybox-w32
• Same backend chain: dsh-sandbox-windows-acl → dsh-sandbox → shell provider
• Session host launched from Git Bash

Symptom

bash itself starts and its builtins work, but every MSYS2 executable fails:

$ for t in ls cat grep sed awk find sort tail head uname whoami which; do "$t" --version >/dev/null 2>&1; echo "$t -> $?"; done
ls -> 127      cat -> 127     grep -> 127    sed -> 127     awk -> 127
find -> 127    sort -> 127    tail -> 127    head -> 127    uname -> 127
whoami -> 127  which -> 127

Each one reports the same failure before any user code runs:

uname.exe: fatal error - NtCreateDirectoryObject(\BaseNamedObjects\msys-2.0S5-<hash>): 0xC0000022

Native Windows binaries are unaffected (git → 0, cmd → 0), as are bash builtins
(echo, redirection, arithmetic, $( )).

Root cause — integrity level forced to Low

The windows-acl backend unconditionally lowers the integrity level when building the
restricted token:

if (api.setTokenInformation(token, 25, info, info.length) === 0)
    throwLastError$1(api, "SetTokenInformation", "TokenIntegrityLevel (Low)");
//                           25 == TokenIntegrityLevel

Confirmed on the running sandboxed process (whoami has to be invoked as the native
C:\Windows\System32\whoami.exe, since the MSYS2 one cannot start):

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

\BaseNamedObjects is a Medium-integrity directory. Windows' mandatory integrity
policy forbids a Low-integrity process from creating objects inside it, so MSYS2's
per-process shared-memory init (\BaseNamedObjects\msys-2.0S5-<hash>) is refused with
STATUS_ACCESS_DENIED.

This is not the two-pass discretionary check described in Defect 2: the object is
being created in a namespace the token may not write to at all, and mandatory labels
are evaluated independently of the DACL. Merging more ACEs into the token default DACL
cannot change this outcome — which is consistent with the observation that the plugin's
native guard (below) makes no difference here.

Why this did not show up before

0.1.6 did not downgrade the integrity level. The same plugin worked under
workspace-write on that version: MSYS2 applets (ls, cat, grep) ran normally.
So this is a regression introduced in the 0.2.0 line, not an inherent MSYS2 or
Windows limitation.

How it relates to Defect 1 / 2

	Mechanism	What breaks
Defect 1	AllocConsole inside a restricted token	any console-subsystem child of the GUI-subsystem entry binary
Defect 2	token default DACL has no SID that is also enabled	creation of unnamed objects (CreatePipe)
Defect 3	mandatory integrity label = Low	creation of objects in Medium-integrity namespaces (\BaseNamedObjects)

They are independent. Applying the Defect 1 fix lets the shell start, and the Defect 2
fix restores pipes, but MSYS2 applets still die on Defect 3.

Suggested fix

Either of:

1. Do not downgrade the integrity level for shells that require global named objects,
   or expose it as a knob on the windows-acl backend (e.g.
   integrityLevel: 'low' | 'medium'), so a plugin whose shell depends on
   \BaseNamedObjects can opt out. This is a small conditional.
2. If Low integrity must remain for security reasons, redirect those objects into a
   namespace the Low token can write — a per-session
   \Sessions\<n>\BaseNamedObjects-style container. That needs cooperation from the
   shell runtime (MSYS2), so option 1 is the pragmatic path.

For reference, read-only avoids the visible failure here only because MSYS2 applets
still cannot start — the mode is simply less commonly exercised with this shell.

Note: this cannot be fixed from the plugin layer

The plugin ships a native guard (msys-token-guard.exe + a Detours hook DLL) that hooks
RtlAddAccessAllowedAce, NtSetInformationToken and CreateProcessW specifically to
let MSYS2 survive WRITE_RESTRICTED. It cannot help with Defect 3 because:

• the integrity level is committed before the guard is spawned (the guard only ever
  runs inside the already-restricted token), and
• NtCreateDirectoryObject is not among the hooked APIs.

So a fix has to happen in dsh-sandbox-windows-acl or in the spawn path, not in a
third-party shell plugin.

---

For completeness, here is the exact probe output from that session:

=== A. shell identity ===
shell    = /usr/bin/bash
version  = 5.3.15(1)-release
msystem  = MSYS
cwd      = /d/workspace/<...>

=== B. write INSIDE workspace ===   INSIDE: OK
=== C. write OUTSIDE workspace ===  OUTSIDE: DENIED        <- sandbox boundary is correct
=== D. native binaries ===          git -> 0, cmd -> 0
=== E. MSYS2 binaries ===           all -> 127 (0xC0000022, NtCreateDirectoryObject)
=== F. guard marker ===             CYGWIN_TESTING=1       <- guard did run

[ZenLiuCN]

patch_dsh.sh
I have made this urgly patch for the version

1. patch launcher as /subsystem:console (so I have to wrote another launcher to hidden the console)
2. patch asar for Everyone sid
   main.c
3. the console hidden launcher

Result:
usable, but should careful with the changes of offical updates.

[ZenLiuCN]

the named pipe problem can be simlply discribe as: Why writable permission not inherit same acl as ready-only has ?

[Bruce-Yii]

I cross-checked a few earlier Windows "workspace-write" reports because several of them look identical at the symptom level but appear to be different failure paths.

My current map is:

• [Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810 / Sandboxed child-process creation triggers Windows error dialog (0xC0000142 / STATUS_DLL_INIT_FAILED) #7836 → same family as Defect 1 here: "0xC0000142 / STATUS_DLL_INIT_FAILED" around restricted child-process / console creation.
• Windows: workspace-write sandbox fails with SetNamedSecurityInfoW Win32 5 when the workspace directory DACL lacks WRITE_OWNER #7504 → separate path: "SetNamedSecurityInfoW" / Win32 5 during ACL provisioning, before the child process is even created.
• This thread, Defect 2 → separate again: token default DACL / "CreatePipe".
• This thread, Defect 3 → separate again: Low integrity blocking MSYS2 named-object creation.

So the broader symptom “Windows "workspace-write" is unusable” currently seems to contain at least four different mechanisms, rather than one root cause.

Would it be useful to keep future reports routed into these separate buckets and cross-link duplicates to the corresponding thread? I can help map new reports when the mechanism is clear.

[ZenLiuCN]

That is useful , but requires an overview for the exists issues, not easy for every defect reporter. Maybe using some index thread is more effect. I just check some other looks like thread, some one report re-install is solution (🤔 not match helped for specific condition) .

[dsh-community-assistant[bot]]

Thanks for the report.