[Bug] [Windows sandbox] schannel TLS fails with SEC_E_NO_CREDENTIALS under workspace-write/read-only (restricted token)

[kalueriw]

结论（中文）

Windows 沙箱在 workspace-write / read-only 模式下用受限令牌
（CreateRestrictedToken，DISABLE_MAX_PRIVILEGE | SANDBOX_INERT | WRITE_RESTRICTED）
启动子进程，导致 schannel 系工具（curl / PowerShell / .NET）的 HTTPS 全部报
SEC_E_NO_CREDENTIALS；OpenSSL 系（Node / Python）不受影响。
已用 danger-full-access 对照实验证明受限令牌是根因。
README 称"网络不受限"与此矛盾，建议文档化或修复。

---

Environment

• OS: Windows 10 Home China, 25H2, build 26200.8875
• Node.js: v24.19.0
• Package: @deepseek-ai/dsh-sandbox-windows-acl@0.1.0-rc.7
• Sandbox mode: workspace-write (read-only assumed affected too)

Summary

In confined modes, any schannel-based HTTPS request from inside the sandbox
fails with SEC_E_NO_CREDENTIALS (0x8009030e). The README states "reads,
network, and process visibility are not [restricted]" — but schannel credential
acquisition actually breaks under the restricted token. OpenSSL-based tools
(Node/Python) are unaffected.

Steps to reproduce

In a workspace-write session:

1. curl.exe -s -m 10 https://www.baidu.com
   → exit 35; verbose shows AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS
2. Invoke-WebRequest -Uri https://www.baidu.com -UseBasicParsing
   → "The underlying connection was closed"
3. Control (works): node -e "fetch('https://www.baidu.com').then(r=>console.log(r.status))"
   → 200

Root cause analysis (evidence chain)

1. The sandbox spawns children under a CreateRestrictedToken with flags
   DISABLE_MAX_PRIVILEGE | SANDBOX_INERT | WRITE_RESTRICTED (0x0D).
2. whoami /all under the restricted token: only SeChangeNotifyPrivilege
   remains; BUILTIN\Administrators is deny-only; Medium integrity level.
3. Certificate stores are NOT the problem — .NET X509Store("My","CurrentUser")
   opens (1 cert) and X509Store("Root","LocalMachine") opens (54 certs).
4. The failure is precisely at credential acquisition:
   SslStream.AuthenticateAsClient throws "No credentials are available in the security package".
5. Control experiment: the SAME Invoke-WebRequest https://www.baidu.com
   succeeds (HTTP 200) under danger-full-access (unconfined token).
   → the restricted token is the necessary & sufficient cause.
6. Node/OpenSSL is immune because it bundles its own Mozilla CA store (120 roots)
   and never calls schannel.

Expected vs actual

• README "Verified boundaries": network should not be restricted; a confined
  child can "open sockets".
• Actual: schannel HTTPS (curl / PowerShell / .NET SslStream) fails in confined modes.

Impact

• Affected: Windows + workspace-write/read-only + schannel-based tools.
• Unaffected: OpenSSL-based tools (Node.js, Python ssl), and danger-full-access mode.

[zoahdev]

核验确认（当前 main HEAD 99f6f02），补一个标志更正 + 机制探针建议：

1. 标志更正：代码里没有 SANDBOX_INERT，是 LUA_TOKEN

packages/sandbox/sandbox-windows-acl/src/token.ts 的 createRestrictedToken：

abi.DISABLE_MAX_PRIVILEGE | abi.LUA_TOKEN | abi.WRITE_RESTRICTED

• LUA_TOKEN（0x4）：把新令牌标记为 LUA（limited user account）分裂令牌的非提升部分——配合 DISABLE_MAX_PRIVILEGE 后只剩 SeChangeNotifyPrivilege（与你 whoami /all 的观察完全一致）；SANDBOX_INERT（0x2）不在这条路径上。
• 限制 SID 列表：workspace-write = [logonSid, world, ...writeSids]，read-only = [logonSid, world]——所以 read-only 模式同样受影响（你的"assumed"成立）。

2. README 矛盾确认

packages/sandbox/sandbox-windows-acl/README.md 原文："Writes are restricted; reads, network, and process visibility are not. WRITE_RESTRICTED intersects write accesses only, so a confined child can read any caller-readable file and open sockets."——"能开 socket"属实，但对 schannel 客户端来说"网络可用"是误导：AcquireCredentialsHandle 失败发生在 TLS 握手之前。建议加一句已知限制：socket 可开，但受限令牌下 schannel 系 TLS 客户端（curl/PowerShell/.NET）可能 SEC_E_NO_CREDENTIALS；沙箱内请用 OpenSSL 系客户端（Node/Python）。

3. 机制探针建议（补上最后一块证据）

你的证据链已经排除证书库本身（My/Root 都能打开），失败精确落在 credential acquisition。还差一步就能完全定位"AcquireCredentialsHandle 到底被哪个受保护对象拒绝"：

• 开启 Microsoft-Windows-Schannel/Operational 事件日志，复现后看 TLS 客户端事件里的失败码；
• 配合安全审计（对象访问审计 + 进程审计）或 Process Monitor 过滤 AcquireCredentialsHandle/CryptAcquireContext 的 ACCESS_DENIED，能拿到具体路径/对象名。

这一步做完，"受限令牌缺哪个权限/对象访问"就从推测变成事实，修复（要么放宽那个对象、要么文档化）才有依据。如果你的环境方便，跑完把结果贴上来，我可以继续跟。

4. 修复/缓解选项（按成本排序）

1. 文档化（最小）：README 已知限制加 schannel 条目 + 沙箱内 OpenSSL 客户端建议；
2. 探针后窄修：如果定位到具体对象（如某个 crypto key container），把该对象的读权限显式加入受限令牌允许集（保留 WRITE_RESTRICTED 语义，只补读）；这比"放行整个网络"窄得多；
3. 显式逃生舱（最重）：config 提供 fullTokenForTls: true（默认 false）让需要 schannel 的子进程用完整令牌，文档明确标注"削弱沙箱"，仅限明确场景——和现有 fail-closed 哲学一致，默认不启用。

5. 回归测试建议

windows-acl 套件已有原生 runner 测试，可以加一条：受限子进程内跑 curl.exe -s https://www.baidu.com——要么断言成功（若将来修了），要么断言"documented failure 路径不崩溃且错误信息明确"（现状），把 README 声明与行为钉在一起，防止将来 README/令牌代码再次漂移。

[kalueriw]

感谢核验和更正！

1. 标志更正收到：已确认源码是
   DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED（0xD = 13），
   以你的更正为准。

2. 探针完成了——被拒对象已精确定位。
   本机（Windows 11 25H2 家庭中文版，build 26200.8875）没有注册
   Schannel/Operational 事件日志频道（提权 wevtutil 也报 15007），
   所以我改用 logman + Kernel-Registry ETW（提权）在 curl 失败的
   同一瞬间抓取内核注册表事件，结果如下：

   • Opcode: CreateKey（EventID 1），Status: 0xC0000022 ACCESS_DENIED
   • RelativeName（被拒键，共十余个）：
     Software\Microsoft\SystemCertificates{CA, Root, AuthRoot,
     Disallowed, SmartCardRoot, TrustedPeople, trust}
     Software\Policies\Microsoft\SystemCertificates{CA, Disallowed,
     Root, trust, TrustedPeople}
     Software\Microsoft\EnterpriseCertificates{CA, Disallowed, Root,
     trust, TrustedPeople}
   • ProcessID = 触发失败的 curl.exe；时间戳与失败严格同步；
     其余所有注册表事件均 Status=0

   结论：AcquireCredentialsHandle 初始化证书库时，对
   SystemCertificates 系列键发起带写访问的打开/创建（CreateKey），
   受限令牌的 WRITE_RESTRICTED 写检查拒绝 → 0xC0000022 →
   SEC_E_NO_CREDENTIALS。这也解释了为什么只读枚举证书库正常
   （读检查不受 WRITE_RESTRICTED 影响）、但 TLS 凭据获取失败。

3. 与你"窄修"方向的呼应：修复可以只针对这几个具体的
   SystemCertificates 注册表键加 capability-SID 写授权（而不是放行
   整个网络或提供 fullTokenForTls），写隔离语义基本不变。
   备选：文档化 + 沙箱内默认 OpenSSL 客户端。

原始 ETL/XML 证据文件我保留了，如需可提供。

[kalueriw]

@zoahdev 补充最新实验结果——"被拒对象"这条路已被证伪，修复方向需要修正：

1. ProcMon 全量抓取（干净的 PML，Python 解析）

在受限令牌沙箱内触发 3 次 curl.exe https://www.baidu.com（退出码 35），
ProcMon 同步抓取全系统事件：

• curl.exe 完整事件序列：2,683 条（含 schannel 路径：
  crypt32.dll / bcrypt.dll / cryptsp.dll / sspicli.dll / sechost.dll 加载与操作）
• 全系统 ACCESS DENIED：0 条

结论：SEC_E_NO_CREDENTIALS 失败全程没有任何文件/注册表/设备访问被拒。

2. ACL 授权实验（针对之前 ETW 看到的 CreateKey 拒绝）

之前 Kernel-Registry ETW 曾捕获 schannel 对
SystemCertificates 系列键的 CreateKey 返回 0xC0000022。
我做了对照实验：给 HKCU 与 HKLM 的
SOFTWARE\Microsoft\SystemCertificates、
SOFTWARE\Policies\Microsoft\SystemCertificates、
SOFTWARE\Microsoft\EnterpriseCertificates（共 6 个父键，ContainerInherit）
授予工作区 capability SID（S-1-4-…，在 restricting 列表内）的
CreateSubKey/SetValue/WriteKey 权限。

• 授权生效：受限令牌进程实测能以写方式打开 …\SystemCertificates\CA
• 但 curl 依旧退出 35（SEC_E_NO_CREDENTIALS）

结论：那些 CreateKey 拒绝是 schannel 容忍的噪音，不是致命因素；
"给被拒对象补授权"（原方案 2）无法修复本 bug。

3. 修正后的结论

失败发生在 schannel 对受限令牌（WRITE_RESTRICTED）的内部处理
——零访问拒绝 + 任何 ACL 授权无效 + danger-full-access（完整令牌）
下同一命令成功（HTTP 200），三者互相印证：
schannel 拒绝为受限令牌构建凭据（其自身的安全设计），
不是"缺哪个对象的权限"。

因此建议：修复方向收敛为

• 方案 1（README 文档化 + 沙箱内 OpenSSL 客户端建议），
• 方案 3（fullTokenForTls: true 逃生舱，默认 false），
• 方案 2（窄授权）可放弃——不存在可授权的对象。

顺带修正：我之前回复里"注册表 CreateKey 拒绝是根因"的判断不成立，
以本实验为准。