Windows sandbox (dsh-sandbox-windows-acl): WRITE_RESTRICTED token breaks Schannel TLS for native HTTPS clients (curl / git / Invoke-WebRequest)

[JimmyReload]

Summary

On Windows, every command run under the sandbox (read-only / workspace-write modes) fails to perform TLS with any Schannel-based client: curl, git (default sslBackend), Invoke-WebRequest, and any .NET HttpClient all fail at AcquireCredentialsHandle with SEC_E_NO_CREDENTIALS (0x8009030E) - before any handshake. DNS resolves and TCP connects fine; the failure is purely in Schannel credential acquisition.

OpenSSL-based clients (node, python, git with http.sslBackend=openssl) work normally inside the sandbox.

Environment

• OS: Windows (reproduced on 19041 and Win11-26200-class builds)
• @deepseek-ai/dsh 0.1.0-rc.6, @deepseek-ai/dsh-sandbox-windows-acl 0.0.1-rc.1 (latest on npm)
• Sandbox backend: Windows ACL restricted-token runner

Repro

Inside any sandboxed shell (e.g. the pwsh tool, workspace-write mode):

curl.exe -v https://www.baidu.com
# Connected to www.baidu.com (IP) port 443
# schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030E)
# curl: (35) schannel: AcquireCredentialsHandle failed ...

Same command run with the normal user token (no sandbox) succeeds (HTTP 200). TCP connectivity inside the sandbox is fine (raw socket to port 443 connects; Test-NetConnection succeeds).

Root cause analysis

The Windows runner wraps commands in a restricted token created via CreateRestrictedToken with:

• flags = 13 = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED
• restricting SIDs = [logon SID, EVERYONE, workspace write SID, private temp SID]

I reproduced the failure outside the sandbox by creating the same restricted token in isolation (same machine, same user, same curl.exe), then exhaustively varied parameters:

Variation	Result
DSH configuration as-is (flags=13, [logon, Everyone, ws SID])	curl exit 35 (Schannel) - reproduced
drop WRITE_RESTRICTED (flags=5 or 0)	child process cannot start (0xC0000022 ACCESS_DENIED at init)
add user SID / BUILTIN\Users / INTERACTIVE / Authenticated Users / SYSTEM to the restricting list	still exit 35
flags=12 / 8 / 9 (drop each individual flag)	still exit 35

Conclusion: the WRITE_RESTRICTED flag is both required for the restricted process to start and the cause of the Schannel failure. No combination of restricting SIDs fixes it, and WRITE_RESTRICTED cannot be removed without breaking process startup. (Adding SYSTEM to the restrict list cannot help because the write access check requires the SID to be present in the token's primary groups too.)

Why this is a bug (not intended behavior)

The package README explicitly states the ACL scheme is about file writes: "writes are restricted; reads, network, and process visibility are NOT". Breaking TLS for every native HTTPS client contradicts that documented contract and is not mentioned anywhere in the READMEs or design notes. This effectively makes curl / Invoke-WebRequest / .NET HttpClient unusable in the default sandbox on Windows.

Suggested directions

1. Document the limitation prominently (short term).
2. Investigate whether the token (or a dedicated Schannel/CNG carve-out) can be constructed so Schannel credential acquisition succeeds while write confinement is preserved - e.g. verifying exactly which object/operation Schannel needs write access to during AcquireCredentialsHandle, and whether a restricted-SID or \Device\CNG-related grant can satisfy it without weakening the write boundary.
3. Consider offering a Windows sandbox backend that does not rely on WRITE_RESTRICTED (or a config to relax token restriction for commands that need native TLS).

Workarounds discovered

• git: git config --global http.sslBackend openssl (or -c http.sslBackend=openssl)
• npm: point the cache at a writable directory (npm_config_cache)
• curl / Invoke-WebRequest: use node / python (OpenSSL) or run outside the sandbox