[Bug?] Windows confined 沙箱下所有 Schannel/SSPI 客户端 HTTPS 失败:SEC_E_NO_CREDENTIALS(受限令牌+Low integrity)

[LCorleone]

环境

• Windows 11 build 26100(PowerShell 5.1.26100.9444)
• DeepSeek Harness 内核 0.2.0-rc.2(@deepseek-ai/dsh-sandbox-windows-acl rc.2,桌面发行版形态)
• C:\WINDOWS\system32\curl.exe 8.21.0(Windows/Schannel 构建)
• 沙箱模式:confined(workspace-write)

现象一句话

沙箱执行环境内,一切依赖 Windows 原生 TLS(Schannel/SSPI)的 HTTPS 客户端在 AcquireCredentialsHandle 阶段即失败:SEC_E_NO_CREDENTIALS (0x8009030e)。同一 exe、同一机器、用户交互会话内完全正常;明文 HTTP 沙箱内正常。

复现

沙箱内(经 ACL runner 受限令牌):

curl.exe -sS -o NUL -w "http_code=%{http_code}`n" https://www.baidu.com/
# http_code=000, exit 35
# schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)

curl.exe -sS http://example.com/   # exit 0 —— 网络与代理通路正常

用户会话(同一 exe、同一 URL):200。

对照矩阵

环境	客户端	HTTPS	说明
沙箱	curl.exe(Schannel)	❌ exit 35	握手前凭据获取失败
用户会话	curl.exe	✅	唯一差异=进程令牌
沙箱	Invoke-WebRequest(.NET)	❌	同一 SSPI 根因(inner: No credentials are available in the security package)
沙箱	curl -k / --cacert	❌ 同错	失败点在证书校验之前
沙箱	Python urllib(OpenSSL)	✅	用户态 TLS 不碰 SSPI
沙箱	明文 HTTP(经代理)	✅	网络层无关

全程无任何 sandbox 裁决输出——不是文件策略拒绝,是令牌形态本身。

根因指认(已实证)

dsh-sandbox-windows-acl 的 runner 对子进程令牌做了三件事:

1. CreateRestrictedToken(flags=13) = WRITE_RESTRICTED | DISABLE_MAX_PRIVILEGES | SANDBOX_INERT,restricting SIDs = [logon SID, Everyone, workspace SID, temp SID];
2. 摘除 Authenticated Users / INTERACTIVE / LOCAL;
3. 降到 Low integrity,再 CreateProcessAsUserW 生成子进程。

实证(whoami /groups):

• 沙箱内:Mandatory Label\Low Mandatory Level (S-1-16-4096),且上述三组不在列;
• 用户会话:Medium (S-1-16-8192) + 完整组表。

已知边界:AppContainer(同为受限令牌+Low IL)是可以用 Schannel 的,所以致命成分到底是 Low IL、restricting SID 列表、还是特权剥离,可能需要判别实验(「仅 WRITE_RESTRICTED 不降 IL」vs「仅降 IL」对照测 AcquireCredentialsHandle)。

建议/想问的

1. 这是否已知限制?若是有意的安全边界,建议在 README 标注「受限令牌下原生 TLS(Schannel)客户端不可用,请用 OpenSSL 栈客户端」;
2. 若非有意:是否可以考虑去掉/条件化 Low integrity 降级(WRITE_RESTRICTED+能力 SID 已承载写管控语义)?

我们的过渡(供同样踩到的人)

沙箱内取 HTTPS 数据一律走 OpenSSL 栈:捆绑 Python(urllib/requests,已验证)或 Node;免限重跑拿正常令牌后原生 TLS 即通。

[LCorleone]

这个discussion会被官方看到吗？

[IsFaser]

我也遇到了.顶一下

[LCorleone]

继续up

[PerryLink]

这个问题已经有人报过三次了，而且其中一次已经被回复过。建议先看那三条，别当新问题提。

三次前科

#3207（2026-08-18）、#4163（2026-08-23）、#2850，标题里都带 SEC_E_NO_CREDENTIALS，全部没有选中答案。其中 #4163 已经有一条回复，结论是：目前没有解法，让 agent 临时换后端（写进 skill 或 agent.md 用 OpenSSL 栈）绕过去。

#4163 的正文和你的对照矩阵几乎是同一个形状。所以你的诉求方向（确认是不是已知限制）**答案是"是"，而且已经有人问过"。

你的事实基本对，但有一处指认错了

token.ts:232 那次调用的 flags 是：

abi.DISABLE_MAX_PRIVILEGE | abi.LUA_TOKEN | abi.WRITE_RESTRICTED   // 0x1 | 0x4 | 0x8 = 13

你写的数值 13 是对的，但你把 0x4 认成了 SANDBOX_INERT —— 它实际是 LUA_TOKEN（受限用户标记）。SANDBOX_INERT 在 DSH 仓库里 0 命中（我换了几组 pattern 查过），而且那个位真值是 0x10，不是 0x4。

这个错认有连带影响：你据此把"LUA 标记"读成了"沙箱惰性位"，然后把它列进"致命成分"的候选清单。清单本身要先改掉。

你另外三组令牌事实都对，我逐条核了：

• token.ts:184-185 的限制列表按模式分（read-only: [logon SID, EVERYONE]；workspace-write: [...加上 workspace SID 和可选 temp SID]）
• :197-203 说明 Authenticated Users 和 INTERACTIVE/LOCAL 两种模式都不在列表里
• index.ts 里 createRestrictedToken 之后紧跟 restrictTokenIntegrity(...)，降到 Low（S-1-16-4096）

不过有一点要说清：上面那个是 restricting list（只用于交叉校验写访问），和令牌自身的组成员表是两回事。你把两者混在一起讲了，维护者大概率会先纠正这一点。

"去掉 Low IL 就能修"这条我建议不要写死

WRITE_RESTRICTED 只对写访问做交叉检查（README :32、:188）。而 AcquireCredentialsHandle 不是写访问。所以单独摘掉 Low 完整性级别大概率修不了这个问题。

你提的判别实验（只保留 WRITE_RESTRICTED 不降 IL / 只降 IL）值得做，但在结果出来之前，别把"Low IL 是元凶"当结论写——那是最弱的一条假设。

⭐ 真正站得住的诉求是文档缺口，而且可以量化

这一条我建议你作为主诉求，因为它客观、可核实、不依赖归因：

• 全仓检索 schannel|SSPI|AcquireCredentialsHandle 在 packages/sandbox 与 packages/subprocess 下 0 命中 —— 也就是说这个限制没有被任何文档记录；
• 而 README.md:125 明写「Writes and deletes are restricted; reads, network, and process visibility are not … a confined child can read any caller-readable file … and open sockets」 —— 这句话会让人以为网络是通的；
• 同时 README.md:122 已经承认 CNG 依赖 keep-alive 组（"early DLL initialization and CNG"），而 CNG 正是 Schannel 取凭据要走的路径。

⇒ 所以你的文档矛盾指控成立且证据充分：README 一边说网络不受限、一边记着 CNG 对某个组有依赖，而完整的边界没有列出来。

建议诉求：在 sandbox-windows-acl/README.md 的已验证边界那一节补一条 Windows Schannel/SSPI 客户端的限制，或者修订 :125 的措辞。这条几乎肯定会被采纳，因为它只是补文档。

一点方法论建议

你这份报告的对照矩阵做得很好（这大概也是 #4163 里没有的），建议保留。但下次先做去重检索——SEC_E_NO_CREDENTIALS 这个词在 Discussions 里一搜就能看到那三条。

另外你帖子里说"想问的"这种措辞，如果改成"已知 #3207/#4163/#2850 报过同一现象、#4163 已有过渡方案，本帖补充的是对照矩阵"，维护者会更快接手。

边界

我核的是 origin/master = 86a402200d（2026-10-15，alpha.4）。packages/sandbox 目录在上一个 master 到这版之间零变更，所以这些行号对最近几个版本都成立。

SEC_E_NO_CREDENTIALS 的精确归因我做不到 —— 那需要在本机跑你提的那组判别实验，而我没有 Windows 受限令牌的复现环境。上面第 4 节特意选了不依赖归因的那条作为主诉求，就是为了让这条报告无论如何都站得住。

[YSXX1013]

“先看那三条，别当新问题”
但问题是那三条也仅仅是和本文同样的问题陈述，唯一的“解法”就是换用openssl——这从本质上并没有解决问题。
“去掉 Low IL 就能修”是不行的，但未必没有可行的工程解法，一味的指责反馈用户我觉得也不是正确的行为——更何况受限模式下的https出现问题并非dsh本意，应当讨论进一步的工程解法。

[LCorleone]

感谢逐条核对，两处指正都认领：

1. flag 语义认错：0x4 是 LUA_TOKEN，不是 SANDBOX_INERT（后者真值 0x10，且本仓库 0 命中）。更正后的成分表：CreateRestrictedToken flags 13 = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED。

2. 两张表混讲：restricting list 只作用于写访问交叉校验；真正让 AcquireCredentialsHandle 拿不到凭据的是令牌组成员表——实测（受影响机器 whoami /groups 与正常会话差集）被摘除的是 Authenticated Users / INTERACTIVE / LOCAL，随后 restrictTokenIntegrity 降到 Low（S-1-16-4096）。原帖把这两层混在一起，抱歉。

「去掉 Low IL 就能修」同意降级为最弱假设——WRITE_RESTRICTED 只拦写访问，AcquireCredentialsHandle 并非写访问，所以 IL 与组表摘除哪个才是必要条件，判别实验（只留 WRITE_RESTRICTED / 只降 IL）出结果前不定论。我们手上有真实受影响机器，会跑完回帖补数据。

前案互链：#3207、#4163、#2850（本帖主诉求从「确认是否已知限制」撤回——是已知限制，且 #4163 的回复已给绕行方案）。

调整后的主诉求是文档缺口，可核实、不依赖归因：

• packages/sandbox 与 packages/subprocess 下 schannel|SSPI|AcquireCredentialsHandle 全仓 0 命中；
• README 写「reads, network, and process visibility are not restricted … can open sockets」，但 Schannel/SSPI 客户端 HTTPS 实际全线失败（凭据获取走 CNG，而 README 自己承认 CNG 依赖 keep-alive 组）；
• 请求：在 verified boundaries 一节补一条 Windows Schannel/SSPI 客户端限制，或修。

给后来者的快速判别签名（沙箱内四连测）：curl/PowerShell HTTPS 失败且错误含 SEC_E_NO_CREDENTIALS（curl exit 35）+ 明文 HTTP 通 + Python/Node（OpenSSL 栈）HTTPS 通 + whoami /groups 缺 Authenticated Users/INTERACTIVE ⇒ 就是这个限制，不是网络/CA/代理问题。过渡方案同 #4163：沙箱内 HTTPS 一律走 OpenSSL 栈（skill 里固化）。