[Windows] ACL sandbox: workspace-write cannot start any child (0xC0000142); read-only works

[jmtcxz]

Hi - reporting a reproducible defect in the Windows ACL sandbox backend. workspace-write
mode cannot start any child process, while read-only works normally. I traced it to the
token's default DACL and verified a fix; apologies if this is already known, I could not find
an existing report (Issues appear disabled, so posting here per CONTRIBUTING).

Summary

In workspace-write, the restricted token's default DACL is granted an ACE for a
capability SID (S-1-4-...). That SID exists only in the token's restricting SID list,
never in its normal SID list. Windows performs two access checks for a WRITE_RESTRICTED
token (normal SIDs first, restricting SIDs second) and requires both to pass. Objects the
child creates without an explicit security descriptor - which the loader does during DLL
initialization - therefore fail at the first check. The child dies before reaching its entry
point with STATUS_DLL_INIT_FAILED (0xC0000142) and produces zero output.

read-only is unaffected because it grants the default DACL to Everyone (S-1-1-0), which
is present in both lists.

Environment

OS	Windows 11 Enterprise, 10.0.26200
Account	built-in Administrator, High IL (no UAC filtering)
Harness	0.2.0-rc.2 (desktop build) - the only version I tested
Affected package	@deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2
Also surfaces via	dsh-sandbox-local, dsh-pwsh-sandbox
Node (bundled)	v24.21.0
koffi	3.1.1
pwsh	7.6.6 (MSIX) - not interpreter-specific, see below

Impact

Once the sandbox is enabled, every ordinary shell command fails, including cmd /c exit 0.
The failure is silent (0xC0000142, zero bytes), which invites misattribution to the shell,
the interpreter, or the machine.

The readiness probe does not catch this. defaultProbeWindowsAcl() in dsh-sandbox-local
exercises --mode read-only only. On an affected host the probe succeeds, the backend is
reported usable/partial, and then every real command fails.

Reproduction

Attached below is a standalone script using only the public AclSandbox API.

Critical detail - the defect is parent-process dependent. AclSandbox builds its restricted
token from the calling process's own token, so who calls init() decides the outcome:

Parent process	read-only	workspace-write
plain node.exe	OK	OK
Electron (ELECTRON_RUN_AS_NODE=1)	OK	CRASH 0xC0000142

Interleaved runs with fresh directories, 3 repetitions each: node always passes, Electron always
fails. Production runs the sandbox runner as the Electron binary (process.execPath in
windowsAclRunnerArgv()), so production is always in the failing column. A test driven from
node will not reproduce it - which is likely why this was missed.

# from a harness checkout, after install/build
$env:ELECTRON_RUN_AS_NODE = '1'
& 'C:\path\to\DeepSeek Harness.exe' repro-acl-workspace-write.mjs `
    packages/sandbox/sandbox-windows-acl/lib/index.js `
    "$env:TEMP\_ws" "$env:TEMP\_tmp"

Observed:

parent  : ...\DeepSeek Harness.exe
mode    : Electron (ELECTRON_RUN_AS_NODE=1) - the failing configuration
read-only       cmd /c exit 0  -> OK
workspace-write cmd /c exit 0  -> CRASH 0xC0000142 (STATUS_DLL_INIT_FAILED)

BUG REPRODUCED: read-only starts a child, workspace-write cannot.

Expected: both modes start a child; under workspace-write the child additionally has write
access inside the granted workspace and remains denied outside it.

Root cause

The two-pass check, from createRestrictedToken() - capability SIDs are passed only as
SidsToRestrict, never added to the token's normal SID list:

api.createRestrictedToken(
  currentToken,
  13,                  // DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED
  0, null,             // SidsToDisable: none
  0, null,             // PrivilegesToDelete: none
  restrictingSids.length / 16,
  restrictingSids,     // <-- capability SIDs live ONLY here
  tokenSlot,
);

And the single default-DACL ACE, from setTokenDefaultDaclGrant():

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

Mode	SID on default DACL	In normal SIDs?	In restricting list?	Pass 1	Pass 2	Result
read-only	Everyone S-1-1-0	yes	yes	pass	pass	works
workspace-write	capability S-1-4-...	no	yes	fail	pass	child dies

Why workspace writes still work despite this: the granted directory's DACL carries the user's
inherited ACEs in addition to the capability ACE, so the directory itself passes both checks.
The default DACL has no such second entry - which is why only newly created objects break.

Fix

The default-DACL grant must name a SID present in both lists.

Option A - narrowest (my recommendation). Use the logon SID, already computed in init()
and already in the restricting list for both modes:

setTokenDefaultDaclGrant(api, restrictedToken, logonSid);

Option B - mirror read-only. Keep the capability SID and add Everyone:

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

(A third option is adding the capability SID to the token's normal SIDs as well, so a
capability-only default DACL can satisfy pass 1. Larger semantic change; flagged rather than
recommended.)

Verification of the fix

Both options applied to an extracted copy of the module, re-run against the same repro:

cap    (product)  read-only OK   workspace-write CRASH 0xC0000142
logon  (Option A) read-only OK   workspace-write OK
    write inside workspace  -> rc=0 file=true    (expected)
    write outside workspace -> rc=9 file=false   (expected)
world  (Option B) read-only OK   workspace-write OK
    write inside workspace  -> rc=0 file=true    (expected)
    write outside workspace -> rc=9 file=false   (expected)

The security boundary is preserved: the workspace stays writable, the escape probe stays denied.
The default DACL only governs objects created without an explicit descriptor; filesystem write
authority remains gated by the capability ACE on the granted trees.

Single-variable isolation (what is not the cause)

Hypothesis	Test	Result
capability SIDs in the restricting list	injected the same S-1-4-... SIDs into read-only's list	still PASS → not it
directory grants (grantWrite)	skipped them	still FAIL → not it
TMP/TEMP rewrite	skipped / redirected	still FAIL → not it
Low integrity label	read-only is also Low	PASS → not it
interpreter (Windows PowerShell 5.1)	cmd.exe fails identically; 5.1 passes under read-only	not it
volume / path	C:, D:, real workspace, %TEMP%	identical → not it
default-DACL SID	swap capability SID → Everyone; nothing else changed	FAIL → PASS

The runner itself is healthy in workspace-write: given a deliberately bad input it reports
cleanly (windows-acl-run: CreateProcessAsUserW failed (Win32 2), exit 127). The failure is
downstream, in the spawned child.

Open question (not reduced)

I could not reduce the parent-dependence to a single token field. The two parent tokens are
identical on everything I could inspect: integrity level, group list, AppContainer status,
capability count, and default-DACL ACEs. The default-DACL effect and the fix are established by
direct experiment; why Electron specifically triggers it is not. That likely needs a kernel
debugger, and I am flagging it rather than guessing.

Two adjacent observations (lower priority)

1. read-only + PowerShell emits a benign stderr line on every run:
   尝试对 'FileSystem' 提供程序执行 InitializeDefaultDrives 操作失败。
   Harmless, but it pollutes stderr and could confuse denial classification, since
   DENIAL_SIGNATURES matching is substring-based.
2. The package README documents that read-only starts PowerShell in ConstrainedLanguage
   because the AppLocker probe cannot write to the temp directory. Worth cross-checking against
   this defect - if that probe is itself affected in some configuration, the reported language
   mode may be conservative rather than accurate.

Happy to provide the full isolation matrix, the exact build steps, or a patch if useful. Thanks!

repro-acl-workspace-write.mjs

#!/usr/bin/env node
/**
 * Minimal reproduction: Windows ACL sandbox "workspace-write" cannot start a child.
 *
 * Usage:
 *   node repro-acl-workspace-write.mjs <path/to/sandbox-windows-acl/lib/index.js> <workspaceDir> <tempDir>
 *
 * In the harness repo the module path is:
 *   packages/sandbox/sandbox-windows-acl/lib/index.js
 *
 * IMPORTANT - this defect is PARENT-PROCESS DEPENDENT.
 * AclSandbox derives its restricted token from the calling process's own token.
 * Under a plain `node` parent the same code PASSES; under the Electron binary that
 * hosts the sandbox runner in production it FAILS. So to reproduce, run this with:
 *
 *   ELECTRON_RUN_AS_NODE=1 <path/to/DeepSeek Harness.exe> repro-acl-workspace-write.mjs ...
 *
 * Exit code: 0 when the bug reproduces, 2 when it does not (e.g. wrong parent).
 *
 * Uses throwaway directories: a workspace-write grant leaves a standing Low integrity
 * label and a capability ACE on the granted root, so do not point it at a real workspace.
 */

import { mkdirSync, rmSync, existsSync } from 'node:fs'
import { join } from 'node:path'

const [, , libArg, wsArg, tmpArg] = process.argv
if (!libArg || !wsArg || !tmpArg) {
  console.error('usage: node repro-acl-workspace-write.mjs <acl lib/index.js> <workspaceDir> <tempDir>')
  process.exit(64)
}

const CMD = process.env.ComSpec || 'C:\\Windows\\System32\\cmd.exe'
const PWSH = process.env.PWSH || 'pwsh'
const STATUS_DLL_INIT_FAILED = 3221225794 // 0xC0000142

const electron = process.env.ELECTRON_RUN_AS_NODE === '1'
console.log(`parent  : ${process.execPath}`)
console.log(`mode    : ${electron ? 'Electron (ELECTRON_RUN_AS_NODE=1) - the failing configuration' : 'plain node - expected to PASS even when affected'}`)

const { AclSandbox, workspaceWriteSid, tempWriteSid } =
  await import('file:///' + libArg.replace(/\\/g, '/'))

const ws = wsArg
const tmp = tmpArg
const escape = join(tmp, '..', 'acl-escape-probe.txt')

rmSync(ws, { recursive: true, force: true })
rmSync(tmp, { recursive: true, force: true })
rmSync(escape, { force: true })
mkdirSync(ws, { recursive: true })
mkdirSync(tmp, { recursive: true })

const fmt = (code) =>
  code === 0 ? 'OK'
  : code === STATUS_DLL_INIT_FAILED ? 'CRASH 0xC0000142 (STATUS_DLL_INIT_FAILED)'
  : `exit=${code}`

async function spawnChild(sb, command, args) {
  const child = sb.spawn({ command, args, stdio: 'inherit' })
  const { exitCode } = await child.wait()
  return exitCode
}

const results = {}

// --- 1. read-only: a child under a Low-integrity write-restricted token ---
{
  const sb = new AclSandbox({ writableDirs: [], tempDir: null, mode: 'read-only' })
  await sb.init()
  try {
    results.readOnly = await spawnChild(sb, CMD, ['/c', 'exit', '0'])
    console.log(`read-only       cmd /c exit 0  -> ${fmt(results.readOnly)}`)
  } finally { sb.dispose() }
}

// --- 2. workspace-write: the same token, plus the capability write SIDs ---
{
  const sb = new AclSandbox({
    writableDirs: [ws],
    tempDir: tmp,
    mode: 'workspace-write',
    writeSid: workspaceWriteSid(ws),
    tempWriteSid: tempWriteSid(tmp),
  })
  await sb.init()
  try {
    results.workspaceWrite = await spawnChild(sb, CMD, ['/c', 'exit', '0'])
    console.log(`workspace-write cmd /c exit 0  -> ${fmt(results.workspaceWrite)}`)

    // Only meaningful once the child starts: confirm the write boundary still holds.
    if (results.workspaceWrite === 0) {
      const inside = join(ws, 'probe-inside.txt')
      const sIn = `try { Set-Content -LiteralPath '${inside}' -Value hi -ErrorAction Stop; exit 0 } catch { exit 9 }`
      const rcIn = await spawnChild(sb, PWSH, ['-NoLogo', '-NoProfile', '-NonInteractive', '-Command', sIn])
      console.log(`  write inside workspace   -> rc=${rcIn} file=${existsSync(inside)}   (expect rc=0 file=True)`)

      const sOut = `try { Set-Content -LiteralPath '${escape}' -Value hi -ErrorAction Stop; exit 0 } catch { exit 9 }`
      const rcOut = await spawnChild(sb, PWSH, ['-NoLogo', '-NoProfile', '-NonInteractive', '-Command', sOut])
      console.log(`  write outside workspace  -> rc=${rcOut} file=${existsSync(escape)}   (expect rc=9 file=False)`)
    }
  } finally { sb.dispose() }
}

console.log('')
const reproduced = results.readOnly === 0 && results.workspaceWrite === STATUS_DLL_INIT_FAILED
if (reproduced) {
  console.log('BUG REPRODUCED: read-only starts a child, workspace-write cannot.')
} else if (!electron && results.workspaceWrite === 0) {
  console.log('NOT reproduced - expected under a plain node parent. Re-run under the Electron')
  console.log('binary with ELECTRON_RUN_AS_NODE=1 (see the header of this file).')
} else {
  console.log('NOT reproduced under this host/parent combination.')
}
process.exit(reproduced ? 0 : 2)

[PerryLink]

0xC0000142 在这个包里有两个已记录的成因——请先确认你排除的是哪一个之差

1. 文档里已有的两处

packages/sandbox/sandbox-windows-acl/README.md：

• :102：workspace-write（logon SID、Everyone、workspace SID、temp SID）与 read-only（logon SID、Everyone，无 write SID）都会 spawn 一个 Low 完整性令牌；keep-alive 组（logon SID + Everyone）在两种模式下都必须存在——

  without it, early DLL initialization dies with 0xC0000142 and CNG crashes pwsh with 0xE0434352.

• :127：Console isolation is unavailable — 用 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程会在 DLL 初始化期死掉，错误是 STATUS_DLL_INIT_FAILED（0xC0000142）；因此子进程共享宿主控制台，而基于管道的 stdio 重定向不受影响。

⇒ 也就是说：同一个错误码，至少有两个已知触发条件（keep-alive 组缺失 / 控制台隔离标志）。你说"workspace-write 连任何子进程都起不来，而 read-only 正常"——这个对照很关键，因为 :102 说两种模式理应都有 keep-alive 组；如果 read-only 正常而 workspace-write 不行，差异就更可能在 write SID / 受限令牌的默认 DACL这一侧，而不是 keep-alive 组。

2. 文档里确实谈到了"令牌默认 DACL"

同文件 :186："…the Win32 layer's default SD template, not the token default DACL"，并指出 "the restricted token's default DACL carries a full-access restricting-SID ACE"。

⇒ 你指的那条路径（受限令牌的默认 DACL 里有一条能力 SID 的 ACE）与文档讨论的是同一个对象。请把你观测到的 ACE 与 :186 那句话并排引用——这样维护者能立刻看出"是 :186 描述的那条 ACE 出了偏差"，还是"另一条 ACE"。

3. 请补三样（能把这三点一次分开）

1. read-only 与 workspace-write 两次的令牌默认 DACL 对照（你既然已追到默认 DACL，把两次的差异列出来即可）；
2. 失败子进程的启动标志（是否带 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE）——这一条直接对应 :127；
3. 0xC0000142 的原文出处（哪一行日志、哪个组件报的），因为 :102 与 :127 报出的措辞不同（一个直接给码、一个给 STATUS_DLL_INIT_FAILED）。

4. 版本口径

你这条没写版本。当前最新是 0.2.1-alpha.1（latest 现在 = 0.2.0-rc.2，不再是我 09 月说的停在 0.1.5-rc.3，见登记表 §0.170）。请补上你复现的版本——sandbox-windows-acl 在 0.2 线有过改动（例如新增"ACL 拒绝诊断技能"），版本基线会直接影响这条是否仍成立。

一条边界

我确认的是文档对 0xC0000142 的两处成因、以及 :186 对令牌默认 DACL 的讨论（足以说明"同一错误码有多因、需先排除"）。你那台机器上到底是哪一条，要看你补的第 3 节证据——我没有在 Windows 上跑受限令牌。