Windows restricted-token sandbox: Schannel TLS fails with SEC_E_NO_CREDENTIALS

[lili-sxdt]

DSH 缺陷 / 文档反馈 — Windows 沙箱受限 token 阻断 Schannel TLS 凭据

面向 DeepSeek Harness (DSH) 项目组的 bug / 文档缺陷反馈。
起草日期：2026-08-23 ｜ 提交人：sxdtlili@qq.com
性质：行为与文档不符（documentation/behavior mismatch） + 一个未文档化的可用性缺口。

中文概要（供快速审阅）

DSH 在 Windows 上的沙箱（dsh-sandbox-windows-acl）用一个受限令牌（WRITE_RESTRICTED + DISABLE_MAX_PRIVILEGE + LUA_TOKEN）约束被沙箱包裹的 shell 子进程。这个令牌只拦截写访问（文档如此声明），但顺带让 Windows 的 Schannel（系统 TLS 提供方）拿不到客户端凭据，导致走 Schannel 的工具——curl.exe、git.exe、Invoke-WebRequest、PowerShell 的 SslStream（以及本环境里的 pip）——在 TLS 握手阶段全部失败（SEC_E_NO_CREDENTIALS）。而 OpenSSL 栈的 Python 网络（requests/urllib）完全不受影响，harness 进程自身的 web_search/web_fetch（不被沙箱包裹）也正常。

DSH 文档多处声明"网络不受限（network stays unrestricted）"、"本 seam 不表达任何网络限制"、"读写/网络/进程可见性不受限"。这些说法在裸 socket / 原始 TCP 层面成立（TCP 连接确实能建立），但对 Schannel 型 TLS 不成立，会误导用户以为沙箱 shell 能正常走 HTTPS。建议修正文档措辞，或将"让受限令牌具备 Schannel 凭据"作为一个明确的安全决策，而不是让这一能力缺口继续作为未文档化的副作用存在。

---

提交信息（可直接复制）

提交目标（GitHub Issues）

• 仓库：deepseek-ai/deepseek-harness（DeepSeek AI 官方）
• 提交页：https://github.com/deepseek-ai/deepseek-harness/issues → "New issue"
• CLI：gh issue create --repo deepseek-ai/deepseek-harness ...（需在非沙箱终端 + 已认证）

标题

• 英文：Windows restricted-token sandbox: Schannel TLS fails with SEC_E_NO_CREDENTIALS
• 中文：Windows 受限 token 沙箱导致 Schannel TLS 失败（SEC_E_NO_CREDENTIALS）

一句话摘要

• 英文：On Windows, the DSH sandbox's restricted token (DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED) prevents Schannel from acquiring client credentials, so Schannel-based TLS clients (curl/git/Invoke-WebRequest/pip) fail at the handshake with SEC_E_NO_CREDENTIALS, while raw TCP sockets and OpenSSL-based clients (Python requests/urllib) still work — contradicting the docs' claim that "network stays unrestricted."
• 中文：在 Windows 上，DSH 沙箱的受限 token（DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED）让 Schannel 拿不到客户端凭据，导致走 Schannel 的工具（curl/git/Invoke-WebRequest/pip）在 TLS 握手阶段即失败（SEC_E_NO_CREDENTIALS），而裸 TCP 与 OpenSSL 栈的 Python（requests/urllib）仍正常工作——这与文档"网络不受限"的声明不符。

一次性复现（issue 评论区/邮件开场白）

Repro (one-liner): from a sandboxed Windows shell run curl -I https://api.deepseek.com — it fails with SEC_E_NO_CREDENTIALS; run the same URL over Python urllib and it succeeds. Root cause is the restricted token stripping Windows Schannel client credentials.

---

Summary

On Windows, the DSH sandbox (@deepseek-ai/dsh-sandbox-windows-acl) wraps the sandboxed shell child in a restricted token built with
CreateRestrictedToken(..., flags = 13, ...) where 13 = DISABLE_MAX_PRIVILEGE(0x1) | LUA_TOKEN(0x4) | WRITE_RESTRICTED(0x8).
This token intersects writes only (as documented), but it also prevents Windows Schannel (the OS TLS provider) from acquiring client credentials,
so every Schannel-based HTTPS/TLS client fails at the handshake with SEC_E_NO_CREDENTIALS (0x8009030e).

Not affected: raw TCP sockets (connect succeeds), OpenSSL-based clients (Python requests/urllib), and the harness node process (e.g. web_search/web_fetch), which is not wrapped by the restricted token.

Contradiction with docs: DSH docs state the sandbox expresses "no network ... restrictions" and that "network stays unrestricted / reads, network, and process visibility are not [restricted]". This is true for raw sockets but not for Schannel-based TLS.

Environment

• Product: DeepSeek Harness — @deepseek-ai/dsh 0.1.1-rc.2
• Packages: @deepseek-ai/dsh-sandbox, @deepseek-ai/dsh-sandbox-local, @deepseek-ai/dsh-sandbox-windows-acl, @deepseek-ai/dsh-bash-sandbox / @deepseek-ai/dsh-pwsh-sandbox
• OS: Windows, sandbox mode workspace-write (ACL restricted-token runner)
• Network client tested: Windows PowerShell 5.1 (pwsh), git, curl.exe, Python 3.14 (urllib)

Expected vs. Actual

	Expected (per docs)	Actual
Raw TCP socket (443)	unrestricted	✅ works (connect succeeds)
Schannel-based TLS (curl/git/Invoke-WebRequest/SslStream)	should work ("network unrestricted")	❌ fails at handshake — SEC_E_NO_CREDENTIALS
OpenSSL-based TLS (Python requests/urllib)	should work	✅ works (reaches server)
Harness web_search/web_fetch	not sandboxed	✅ works

Root cause & evidence

The restricted token is built in machine-independent DSH code with a fixed flag set that strips privileges and produces a limited/write-restricted token. Under this token:

1. Schannel cannot acquire client credentials → SEC_E_NO_CREDENTIALS.

• curl.exe -I https://api.deepseek.com → curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
• Invoke-WebRequest / .NET SslStream.AuthenticateAsClient → Exception calling "AuthenticateAsClient": No credentials are available in the security package
• git ls-remote https://github.com/... → Failed to connect to github.com:443 ... Could not connect to server

2. Token is privilege-stripped (consistent with DISABLE_MAX_PRIVILEGE):

• whoami /all lists only SeChangeNotifyPrivilege (bypass traverse checking); a normal interactive token carries many more.

3. Serialization matches a genuine network, not a firewall:

• Raw TCP connect to github.com:443, www.baidu.com:443, registry.npmjs.org:443, pypi.org:443, api.deepseek.com:443, *.deepseek.com:443 all succeed; only www.google.com:443 fails to answer (SYN-level, unrelated — Google's resilience to probes).

4. OpenSSL path is unaffected (decisive contrast):

• python -c "import urllib.request; urllib.request.urlopen('https://api.deepseek.com')" → HTTPError 401: 'Authorization Required' — i.e. TLS handshake succeeded and the request reached the server (401 = no API key, as expected).

Reproduction

# 1) TCP works — no network firewall
$c = New-Object System.Net.Sockets.TcpClient
$c.Connect("api.deepseek.com",443); "TCP OK"

# 2) Schannel-based TLS fails
curl.exe -I https://api.deepseek.com     # SEC_E_NO_CREDENTIALS

# 3) OpenSSL-based TLS works
python -c "import urllib.request; urllib.request.urlopen('https://api.deepseek.com')"  # 401 (reached server)

# 4) Restricted token — stripped privileges
whoami /all

Impact

• Broken in the sandboxed Windows shell: git clone, curl, Invoke-WebRequest, PowerShell TLS, and pip (in this environment) — all the native-Windows TLS tools fail at the handshake.
• Not broken: Python requests/urllib (OpenSSL) and harness-level web_search/web_fetch.
• Practical consequence: the model's sandboxed shell cannot perform ordinary HTTPS work that relies on Schannel (git operations, downloads, PowerShell web calls), even though the host has full internet (the harness node process itself reaches api.deepseek.com for LLM + web search).

Suggested resolution (options)

1. Documentation-only (lowest risk): Amend the "network is unrestricted / seam expresses no network restrictions" statements in dsh-sandbox/README.md, dsh-bash-sandbox/README.md, and dsh-sandbox-windows-acl/README.md to note that, on the Windows restricted-token runner, Schannel client-credential acquisition fails, so Schannel-based TLS clients are unavailable; OpenSSL-based and harness-level clients are unaffected.
2. Behavioral change (needs a deliberate security decision): If sandboxed-shell network access is desired, provide a mechanism for Schannel credentials under the restricted token (or route HTTPS through a non-Schannel path), explicitly weighing the fact that the current behavior is arguably security-positive (it prevents HTTPS-based exfiltration / arbitrary downloads from the sandboxed shell).
3. State the intent: Either way, the current limitation should be a documented, deliberate choice rather than an unplanned side effect, so callers don't rely on "network unrestricted" to mean Schannel-based TLS works.

Scope & confidence

• Observed on a single Windows host, DSH 0.1.1-rc.2, workspace-write sandbox (2026-08-23).
• Root-cause inference is high-confidence: the token-construction flag set is machine-independent DSH code, and the observed symptoms (stripped privileges + Schannel SEC_E_NO_CREDENTIALS + working OpenSSL) follow directly from it.
• Cross-machine confirmation is pending (has not been reproduced on a second Windows host). Treat "affects all Windows DSH sandboxes" as a strong inference, not a verified universal fact.
• Note: the OpenSSL-works finding was already captured locally in this workspace (research-assistant/docs/network-verification.md, 2026-08-16); this report is the upstream-facing version.

References

• @deepseek-ai/dsh-sandbox/README.md — "File effects are the whole policy vocabulary — the seam expresses no network, process, syscall, device, or credential restrictions."
• @deepseek-ai/dsh-bash-sandbox/README.md — "File effects only ... Network stays unrestricted"; Known Limitations: "Confinement covers file effects only — network restriction ... absent."
• @deepseek-ai/dsh-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 ... open sockets."
• @deepseek-ai/dsh-sandbox-windows-acl/lib/types/token.d.ts + lib/types/win32-abi.d.ts — DISABLE_MAX_PRIVILEGE = 1, WRITE_RESTRICTED = 8, LUA_TOKEN = 4; createRestrictedToken(..., 13, ...).
• @deepseek-ai/dsh-web-search-deepseek/README.md — harness-level web_search reaches the network via ctx.web → POST {baseURL}/messages (DeepSeek Anthropic-compatible API), outside the sandbox.

[SenkjM]

目前无解，写skill或者agent.md让它临时换后端为OpenSSL就行