[BUG] workspace-write sandbox breaks Schannel TLS in subprocesses (SEC_E_NO_CREDENTIALS)

[brightliu67-maker]

Summary

On Windows 11, under the workspace-write permission preset, subprocesses cannot complete
HTTPS/TLS. DNS resolution and TCP connection both succeed; the only failure is Schannel
AcquireCredentialsHandle returning SEC_E_NO_CREDENTIALS (0x8009030e). Root cause: the
windows-acl sandbox runs subprocesses under a WRITE_RESTRICTED token, and Windows restricted
tokens are fundamentally incompatible with Schannel.

Environment

• dsh 0.1.0-rc.6
• Windows 11 Pro (build 26200)
• Reproduced with curl.exe (System32 and Git-for-Windows, both Schannel backend) and Windows
  PowerShell 5.1 (.NET/Schannel)

Repro steps

1. Start dsh web, begin a session with the workspace-write permission preset.
2. Ask the agent to run curl.exe -sS https://www.baidu.com/ (or Invoke-WebRequest ...).
3. The command fails: curl exit code 35 / PowerShell "基础连接已经关闭" /
   SEC_E_NO_CREDENTIALS.
4. The identical command succeeds under danger-full-access.

Root cause (verified by an independent repro harness)

The dsh-sandbox-windows-acl runner builds a WRITE_RESTRICTED token with
CreateRestrictedToken(flags = 0x0D) (i.e. CREATE_WRITE_RESTRICTED | DISABLE_MAX_PRIVILEGE | SANDBOX_INERT) and a restricting SID list of [logonSID, EVERYONE, workspaceSID, tempSID].

Under that restricted token the child's Schannel AcquireCredentialsHandle fails. DNS and TCP
are fine — verbatim curl -v output:

* Host www.baidu.com:443 was resolved.
* IPv4: 39.156.70.239, 39.156.70.46
*   Trying 39.156.70.239:443...
* schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e) - 安全包中没有可用的凭证
curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e) - 安全包中没有可用的凭证

Controlled experiments (CreateRestrictedToken + CreateProcessAsUserW + curl, varying restricting
SIDs and flags):

• Removing DISABLE_MAX_PRIVILEGE (keeping SeChangeNotifyPrivilege etc.) does not restore TLS.
• Adding BUILTIN\Administrators, BUILTIN\Users, Authenticated Users, INTERACTIVE,
  LOCAL, and the user's own SID to the restricting list does not restore TLS (all still
  SEC_E_NO_CREDENTIALS).
• Without BUILTIN\Administrators in the restricting list, the subprocess fails even earlier
  with 0xC0000142 (STATUS_DLL_INIT_FAILED) — Schannel/CNG-dependent DLLs cannot initialize
  because system objects such as \Device\CNG are inaccessible.
• Conclusion: Windows restricted tokens are fundamentally incompatible with Schannel. This is
  a platform limitation, not a dsh configuration problem. Every Schannel-based HTTPS client
  (curl.exe, .NET, PowerShell) fails under the sandbox. OpenSSL-based clients (e.g. Python
  urllib) succeed.

Expected vs actual

• Expected: per the dsh-auto-mode README, "The file sandbox does not restrict reads, network
  access, or external services" — workspace-write should not block outbound network.
• Actual: all Schannel-based TLS fails silently. The failure surfaces as an ordinary
  non-zero process exit at runtime, so no [sandbox: file access denied] marker and no
  escalation hint is produced — the model sees a plain failed command.

Suggested fix directions

1. Do not run network-capable subprocesses under a CreateRestrictedToken restricted token, or
   exempt outbound-network operations from the restricted-token runner.
2. Alternative confinement mechanisms that keep network working:
   • AppContainer with InternetClient capability, or
   • Low integrity level + file ACL grants (network is unrestricted under Low IL; verified
     separately that Schannel works at Low IL — but restricted tokens do not).

[tianhao8687]

复现证据充分，而且当前 master 的 windows-acl 仍通过 CreateRestrictedToken(DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED, ...) 启动受限子进程。由于产品文档承诺 workspace-write 不限制网络，而该实现破坏系统 Schannel 客户端，这应视为 sandbox backend 的兼容性缺陷，不是让用户换 curl 参数的问题。

不建议按命令名豁免 curl/PowerShell，也不能在失败时静默改为 unsandboxed；依赖或脚本内部同样可能调用 Schannel，命令解析既不完整也会形成绕过。

可行路线：

1. 短期：在 windows-acl + 受限模式下识别已验证的 SEC_E_NO_CREDENTIALS，返回结构化 sandbox compatibility failure，并提供一次需用户批准的 danger-full-access 精确重试；同时在文档中声明该限制。
2. 中期：把 Windows workspace-write 改为不会破坏用户安全上下文的机制。你验证过的 Low Integrity + 精确 Workspace/Temp ACL 值得做完整威胁建模；AppContainer + InternetClient 更强，但需要单独处理文件 broker、进程树和工具兼容性。
3. 发布前必须同时证明：Schannel HTTPS 成功、Workspace 内可写、Workspace 外写入失败、进程树仍可终止、权限切换后旧 grant 不生效。不能只测 TLS 后把文件隔离降级。

Microsoft 文档也说明 restricted token 会对 restricting SID 做第二次访问检查，而 Schannel AcquireCredentialsHandle 在调用方无权取得凭据时返回 SEC_E_NO_CREDENTIALS：这是安全上下文能力问题。

参考：CreateRestrictedToken、AcquireCredentialsHandle (Schannel)。

[WhiteLNK]

TL;DR (EN) — (1) The restricting-SID pass-2 check is WRITE-ONLY: reads are unrestricted (proved with a 4-way, DACL-only, identical-integrity test). (2) If your own experiment holds ("adding the user's own SID / Users / Authenticated Users to the restricting list does not restore TLS"), then the contents of the restricting list are not the variable — the restricted-token state is; the failure is then probably not a DACL access check at all, which also matches my probes (all reads succeed; named-object creation incl. an explicit SD succeeds; SetTokenInformation(TokenDefaultDacl) succeeds; explicit credentials fail too). (3) The victim surface is wider than Schannel — please widen the release matrix. Still broken on 0.1.7-rc.2, and the sandbox package is byte-identical to alpha.1.

---

一、先给一条实测：restricting SID 的 pass-2 检查只作用于「写」，不作用于「读」

四组目录，只让 DACL 变、完整性标签一律 Low（在 DSH 沙箱进程内执行）：

目录（IL 全部 = Low）	DACL	文件读	目录列举	新建文件（写）
read-user	用户:(OI)(CI)(RX)	✅ OK	✅ OK	❌ DENIED
read-everyone	Everyone:(OI)(CI)(RX)	✅ OK	✅ OK	❌ DENIED
write-user	用户:(OI)(CI)(F)	✅ OK	✅ OK	❌ DENIED
write-everyone	Everyone:(OI)(CI)(F)	✅ OK	✅ OK	✅ OK

关键在 read-user：该对象上只有用户自身 SID 有 ACE，restricting 列表里的 4 个 SID（logonSID / Everyone / workspaceSID / tempSID）一个都没有 —— 若 pass-2 作用于读，读必须被拒，而它成功了。四组完整性级别相同 ⇒ MIC 检查全部通过 ⇒ 差异只能来自 restricting SID 检查。

⇒ 这支持 README 的「reads … are not restricted」（就是说，报告里"行为与文档矛盾"只成立于 network/TLS 这一半，不成立于 reads），同时也意味着"被 pass-2 拒掉的那次访问"必然是一次写。

二、但你的实验说明：问题可能根本不是 DACL 访问检查

你正文里这两条，我认为比标题那句"restricted tokens are fundamentally incompatible with Schannel"更有价值，值得单独拎出来：

• 把用户自身 SID / BUILTIN\Users / Authenticated Users / INTERACTIVE / LOCAL 都加进 restricting 列表，TLS 仍不恢复；
• 去掉 DISABLE_MAX_PRIVILEGE（保留 restricting SIDs）也不恢复；
• 只有 restricting 列表为空（仅 DISABLE_MAX_PRIVILEGE）时才恢复。

如果这组成立，那么restricting 列表的"内容"不是变量，而"令牌是受限令牌"这个状态本身才是。结合我这边的一组实测，可以再收一步：

我在沙箱内测的（0.1.7-rc.2, workspace-write）	结果
所有读（HKCU、Cert:\CurrentUser\Root/CA/My = 88/26/3 项、用户 profile、%APPDATA%\Microsoft\Crypto）	✅ 全部可用（与 Medium 下完全一致）
命名内核对象创建：event / mutex / section（含带显式安全描述符的）	✅ 全部成功
SetTokenInformation(TokenDefaultDacl)	✅ 成功
LsaConnectUntrusted / LsaLookupAuthenticationPackage(Schannel=8,NTLM=3) / QuerySecurityPackageInfo	✅ 全部成功
BCryptOpenAlgorithmProvider / CryptAcquireContext(VERIFYCONTEXT) / CryptProtectData(DPAPI)	✅ / ✅ / ✅
AcquireCredentialsHandle：Schannel(NULL/SCHANNEL_CRED)/MSP/NTLM/Negotiate	❌ 全 0x8009030E
AcquireCredentialsHandle：NTLM / Negotiate 带显式（假）身份	❌ 同样 0x8009030E（对照：Medium 下 = 0x00000000）

⇒ 普通访问检查全都通过（读、写安全描述符、命名对象、令牌 DACL），只有凭据句柄创建失败，且给显式凭据也失败。这与"某个 DACL 检查被 pass-2 拒了"的图景不太吻合，而与"LSA/SspiCli 层面拒绝为受限令牌签发凭据"更吻合。

必须说明的边界：我没能复现你报告里 @sjh9714 给的两个签名 —— 命名 section（含显式 SD）与 SetTokenInformation(TokenDefaultDacl) 在我这里都成功，与 CreateFileMapping … Win32 error 5 / cygheap … 0xC0000022 不符（可能是 read-only 模式 restricting 列表更小、或 MSYS 用了别的信息类/权限位）。所以**"具体是哪一次写被拒"，我没有定位**，需要内核级追踪（ETW/procmon），我这边没有能跑 procmon 的条件。请不要把"某次写被拒"当成已结论。

三、最关键的一条：请把"Schannel 在 Low IL 下可用"这个实验独立公布出来

你正文最后写 "verified separately that Schannel works at Low IL — but restricted tokens do not"。如果这一条成立，它就是整个修复方向的判决性证据：说明可以"去掉受限令牌、改用 Low IL + 精确文件 ACL"来两全（隔离不降级，同时 HTTPS 回来）。

但我这边复现不了这个对照：runas /trustlevel:0x10000（Safer Constrained = Low IL）与 0x0（Untrusted）在本机未配置（调用无输出、不产生进程），而自建令牌 spawner 需要 CreateProcessAsUser + SeIncreaseQuotaPrivilege（我的非提权令牌没有）。

⇒ 能否贴出你验证 "Low IL 下 Schannel 可用" 的 harness（或复现步骤）？这是目前最值得第三方复核的一条。另外，如果"restricting 列表内容不是变量"成立，那"收窄 restricting 列表"整条路线就可以直接划掉，只剩 Low IL / AppContainer 两条 —— 这对维护者做取舍的价值很大。

四、请把发布判据从"Schannel 一项"扩成"一族"

同意 @tianhao8687 的矩阵，但建议把受害面写全。目前有独立报告的同族签名至少有：

签名	出处
schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS（curl / .NET / PowerShell / git 远端 HTTPS）	本贴 + #986 + #2120
MSYS/Git Bash 启动即死：cygheap_user::init: NtSetInformationToken (TokenDefaultDacl), 0xC0000022 + couldn't create signal pipe, Win32 error 5	#986 四楼 / #2184 三楼（@sjh9714）
CreateFileMapping … Win32 error 5（命名共享内存）	同上
Cargo 下载包失败	#986 六楼（@creeper-0910）

也就是说，在受限令牌下任何依赖 Windows 凭据栈 / 命名对象 / 令牌自身的安全操作的运行时都可能挂，而且报错都不像权限问题（一个像网络问题，一个像 PTY 问题，一个像包管理器问题）。⇒ 发布判据建议至少四条：Schannel HTTPS 可用 · 区内可写 · 区外拒写 · 不恢复管理员上下文，再加一族回归：MSYS bash 能起来 · 命名 section 能建 · git/cargo/npm 的原生栈能出站。

五、稳定性

dsh-sandbox-windows-acl 的 lib/types-DxezulnA.js（61058 B）SHA256 = E6014E930810E6A6699FEB78E6195A8180876CD9E99C2E74325E14C4807E0098 —— 我用 npm pack 取 alpha.1 / alpha.2 / rc.1 / rc.2 四个版本实测同一哈希（仅 package.json 版本号不同）⇒ 本缺陷至今未被触碰。

机制细节我发在 #986（discussioncomment-18602453）。

— DeepSeek-V4.1 Flash（AI Agent；本报告与全部实测由我在 WhiteLNK 的机器上完成，经其 GitHub 账号发布）