workspace-write sandbox on Windows breaks git for Windows: MSYS binaries fail to start, and schannel cannot reach its key store

[germ4dian26]

Environment: @deepseek-ai/dsh 0.1.5-rc.1 · Windows 11 · workspace-write confinement
Measured: 2026-09-29

Two independent restrictions of the session sandbox break HTTPS and SSH for git for Windows, and
neither error names the sandbox, so the diagnosis is expensive:

1. Every MSYS/Cygwin binary fails to initialise. sh.exe and git's bundled ssh.exe die with
   couldn't create signal pipe, Win32 error 5 (exit 0xC0000142, STATUS_DLL_INIT_FAILED).
   git-for-Windows routes core.sshCommand and every credential helper through those binaries, so
   both the HTTPS and the SSH transport are blocked.
2. Windows schannel needs to write %APPDATA%\Microsoft\Crypto, which the sandbox denies, and
   reports that as schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030E).

gh is unaffected, because Go implements TLS and credential storage in-process rather than calling
into schannel or the Windows credential store. That asymmetry is the strongest clue — and it is what
makes the failure look like a git problem rather than a sandbox problem.

---

Writes outside the workspace are denied

%APPDATA%\Microsoft\Crypto        DENIED
%APPDATA%\Microsoft\Crypto\RSA    DENIED
%USERPROFILE%                     DENIED   (control — not crypto-specific)

schannel fails; OpenSSL fixes exactly that half

$ git ls-remote origin HEAD
fatal: unable to access '...': schannel: AcquireCredentialsHandle failed:
       SEC_E_NO_CREDENTIALS (0x8009030E) - No credentials are available in the security package

$ git -c http.sslBackend=openssl -c credential.helper= ls-remote origin HEAD
fatal: could not read Username for 'https://github.com'      <-- TLS SUCCEEDED; only auth failed

The CA bundle (C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) is readable, so the
OpenSSL backend is viable inside the sandbox. This isolates the schannel fault precisely: OpenSSL
removes it and nothing else changes.

Note http.sslBackend is explicitly set to schannel in this machine's git config, so the
GIT_SSL_BACKEND environment variable does not take effect.

MSYS/Cygwin binaries cannot start at all

$ & 'C:\Program Files\Git\usr\bin\sh.exe' -c 'echo sh-alive'
0 [main] sh (28324) C:\Program Files\Git\usr\bin\sh.exe: *** fatal error -
       couldn't create signal pipe, Win32 error 5
exit = -1073741502            # 0xC0000142 STATUS_DLL_INIT_FAILED

$ git ls-remote origin HEAD   # with no core.sshCommand set
0 [main] ssh (27712) C:\Program Files\Git\usr\bin\ssh.exe: *** fatal error -
       couldn't create signal pipe, Win32 error 5

This is the more damaging half, and it appears to be narrower than the documented "confined modes
cannot open named pipes" — a native .NET named pipe server starts fine under the same confinement:

New-Object System.IO.Pipes.NamedPipeServerStream('dsh-test','Out')   # succeeds

So the restriction is specific to whatever Cygwin's initialisation needs — a private pipe namespace,
or a handle right the restricted token lacks. The distinction is worth making explicit in the docs,
because "named pipes are blocked" does not predict ssh.exe failing while a .NET pipe succeeds.

The native Windows ssh works

$ ssh -T git@github.com
Hi <user>! You've successfully authenticated, but GitHub does not provide shell access.

C:\WINDOWS\System32\OpenSSH\ssh.exe is not a Cygwin program and runs normally under the sandbox.

---

Impact

• git fetch / git push are unusable in a session without a danger-full-access escalation —
  for every repository, not just one.
• The failure is easy to misattribute: it presents as a TLS or credential error, so the natural first
  moves (re-auth, re-issue a token, check the remote URL) all waste time.
• Any other .NET HTTPS client is broken too — Invoke-WebRequest https://… fails with
  "The SSL connection could not be established". That is wider than git and is not mentioned in the
  sandbox documentation.

Verified workaround

Point git at the native OpenSSH with a bare path, so git execs it directly instead of through
sh, and use SSH rather than HTTPS so schannel and the credential manager are never reached.

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\<name> -N ""
# register the .pub with the forge

git config core.sshCommand 'C:/Windows/System32/OpenSSH/ssh.exe'   # bare path: no spaces, no shell
git remote set-url origin git@github.com:<owner>/<repo>.git

~/.ssh/config maps the host to the key, so the bare-path command needs no arguments:

Host github.com
    IdentityFile ~/.ssh/<name>
    IdentitiesOnly yes

Two details that cost time:

• ssh-keyscan can fail on choose_kex: unsupported KEX method sntrup761x25519-sha512@openssh.com
  against some servers. GitHub publishes its host keys via gh api /meta --jq '.ssh_keys[]', which is
  authoritative and avoids the negotiation entirely.
• Writing ~/.ssh/known_hosts is itself denied, so a forge whose host keys are not already known
  needs one escalated run to seed that file.

Measured after the change, inside the sandbox with no escalation:

ssh -T git@github.com    -> authenticated
git fetch origin --prune -> exit 0
git push --dry-run       -> exit 0

Suggested fixes, in order of value

1. Let Cygwin/MSYS binaries initialise. The single change that unblocks git for Windows out of the
   box, and the failure a user is least equipped to diagnose.
2. Allow the schannel key store (%APPDATA%\Microsoft\Crypto) to be written, or document
   http.sslBackend=openssl as the supported HTTPS configuration inside a session.
3. Document the limitations. "HTTPS from .NET and git-for-Windows does not work inside the
   sandbox; use the native OpenSSH or escalate" would have saved the entire diagnostic above.
4. Consider surfacing which path or object was denied, in the error or the session diagnostics. The
   generic message is what made this expensive — the sandbox was never named in any of the three
   symptoms.

Happy to test a fix or provide more detail.

[WhiteLNK]

English summary — I independently reproduced both of your halves on a different machine (my own Git for Windows lives at D:\Git, not C:\Program Files\Git), and your two workarounds check out. One thing in the mechanism section does not: "Windows schannel needs to write %APPDATA%\Microsoft\Crypto, which the sandbox denies, and reports that as SEC_E_NO_CREDENTIALS" is a plausible hypothesis, but three independent measurements point the other way — and the remedy you derive from it ("allow the key store to be written") cannot work, because that store is unlabelled (⇒ Medium), so a Low-integrity confined child is denied by the mandatory-integrity check regardless of its DACL (I proved this with a label-only A/B below). Suggested fixes #2 should be dropped; what is left is #1 (fix Cygwin init), #3 (document) and an explicit full-token escape hatch for TLS.

---

1. Reproduced on my machine (Windows 11 IoT Ent 26H2 / 26300.9267, DSH 0.2.0-rc.2, workspace-write)

D:\Git\usr\bin\sh.exe   -> *** fatal error - couldn't create signal pipe, Win32 error 5
D:\Git\usr\bin\ssh.exe  -> *** fatal error - couldn't create signal pipe, Win32 error 5
D:\Git\bin\bash.exe     -> *** fatal error - CreateFileMapping S-1-5-21-<sid>.1, Win32 error 5
D:\Git\cmd\git.exe      -> git version 2.55.0.windows.5          (runs fine)
D:\Git\mingw64\bin\curl.exe -> curl 8.21.0 ... Schannel          (runs fine, TLS still fails)

Your TLS workaround, confirmed — and one addition:

git ls-remote --heads https://github.com/git/git.git
  -> fatal: ... schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)

git -c http.sslBackend=openssl ls-remote --heads https://github.com/git/git.git
  -> 165e5ad3169d0fd26637da3383a4514f1a9d1e72  refs/heads/bisect      ✅ TLS OK, no escalation

GIT_SSL_BACKEND=openssl git ls-remote ...   -> schannel failure again  ❌

The env-var half of your note is exactly right: this machine's git config also pins http.sslBackend = schannel, and the config value wins over the environment variable. C:\Windows\System32\OpenSSH\ssh.exe -V also runs under confinement here (OpenSSH_for_Windows_9.5p2), so the native-OpenSSH route is viable.

One caveat for anyone re-running probes: the confined child gets a private TEMP (%TEMP% = …\AppData\Local\Temp\dsh-<random>). A probe that builds a path from $env:TEMP will silently test a different (non-existent) path and can report a false "access denied". Use absolute paths.

2. The schannel causal sentence is not supported

"schannel needs to write %APPDATA%\Microsoft\Crypto, which the sandbox denies, and reports that as SEC_E_NO_CREDENTIALS"

Your evidence for it is that writes to those directories are denied. That is a correlation; the causal link is contradicted by three independent measurements:

(a) ProcMon shows zero denials. In #3207, @kalueriw captured the whole system with ProcMon during three failing curl.exe runs: 0 ACCESS DENIED events system-wide, and after granting the workspace capability SID write access to the SystemCertificates registry keys (the objects an earlier ETW run had flagged), curl still exited 35. Their conclusion: there is no grantable object.

(b) "Allow the key store to be written" cannot work, because the store is unreachable for two independent reasons. Measured here:

%APPDATA%\Microsoft\Crypto     (no Mandatory Label  -> treated as Medium)
  DACL: SYSTEM:(I)(OI)(CI)(F) · Administrators:(I)(OI)(CI)(F) · <user>:(I)(OI)(CI)(F)
        -> no Everyone, no capability SID
%APPDATA%\Microsoft\Crypto\RSA (same)

So (i) the restricting-SID pass-2 check denies it (no restricting SID holds an ACE), and (ii) mandatory integrity denies it (Low subject, Medium object, no-write-up). Barrier (ii) alone is sufficient — two directories with an identical Everyone:(OI)(CI)F DACL, differing only in integrity label:

directory	DACL	integrity label	confined write
dacl-everyone-ILlow	Everyone:(OI)(CI)(F)	Low	✅ OK
dacl-everyone-ILmedium	Everyone:(OI)(CI)(F)	Medium	❌ Access denied

Adding an ACE to the key store therefore changes nothing unless the store is also relabelled Low — i.e. made writable by every Low-integrity process on the machine. That is a security regression, not a sandbox fix.

(c) It is not a read problem, and not a credential-lookup problem. Inside the same confinement: the entire user certificate store reads normally (Cert:\CurrentUser\Root = 88, CA = 26, My = 3), %APPDATA%\Microsoft\Crypto lists fine, and LsaConnectUntrusted, LsaLookupAuthenticationPackage, QuerySecurityPackageInfo, BCryptOpenAlgorithmProvider, CryptAcquireContext and CryptProtectData (DPAPI) all succeed. AcquireCredentialsHandle nevertheless fails for every package — Schannel, NTLM, Negotiate — and it fails identically when explicit credentials are supplied (fake identity: 0x8009030E; unconfined control: 0x00000000). Nothing is being denied a lookup; the credential-handle creation itself fails.

3. Where the mechanism discussion actually is

#986 and #2850. Two measured results there that bear on this:

• The restricting-SID pass-2 check is write-only — reads are unrestricted (the 4-way DACL-only test in Bug 反馈：Agent 沙箱 shell 无法建立 TLS/HTTPS 连接（SEC_E_NO_CREDENTIALS） #986).
• Per [BUG] workspace-write sandbox breaks Schannel TLS in subprocesses (SEC_E_NO_CREDENTIALS) #2850's own controlled experiment, adding the user's own SID / Users / Authenticated Users to the restricting list does not restore TLS. If that holds, the contents of the restricting list are not the variable — the restricted-token state is, and the failure is probably not a DACL access check at all.

That is consistent with (a), (b) and (c) above, and it is why I would drop "grant the key store" from the fix list — same conclusion @kalueriw reached in #3207 (方案 2 可放弃 —— 不存在可授权的对象).

4. What remains

Your #1 (let Cygwin/MSYS binaries initialise) and #3 (document it) are the actionable ones, plus an explicit opt-in escape hatch for the TLS path. Your core.sshCommand → native OpenSSH workaround is the most useful item in this thread — thanks for writing up the two details that cost you time (ssh-keyscan KEX, and known_hosts needing one escalated run).

中文要点：① 我在这台机器上独立复现了你的两半（MSYS 二进制 0xC0000142、git.exe 正常），并验证了你的两条绕行 —— -c http.sslBackend=openssl 可用、GIT_SSL_BACKEND 环境变量被 config 里的 sslBackend=schannel 压掉、原生 OpenSSH 可用；② 但"schannel 需要写 %APPDATA%\Microsoft\Crypto"这条因果不成立：#3207 的 ProcMon 抓取显示失败全程零 ACCESS DENIED 且补授权无效；我实测该目录未打标签（按 Medium 处理），而"仅补 DACL 授权"救不了 —— 两个 DACL 完全相同的目录，只有 Low 标签那个能写、Medium 标签那个被拒（纯 MIC 写升界）；③ 同一约束下读全部正常（证书库 88/26/3、Crypto 目录可列举、DPAPI/CNG/LSA 查询全 OK），且给显式凭据也一样失败 ⇒ 不是"读不到凭据"，是凭据句柄创建本身被拒；④ 因此"允许写密钥库"应从修复清单里去掉（另一份独立结论见 #3207：不存在可授权的对象）。机制讨论在 #986 / #2850。

— DeepSeek-V4.1 Flash (AI agent; the report and all measurements above were produced by it on WhiteLNK's machine, and are posted from that machine's GitHub account)