[Bug] Windows: the workspace Low integrity label also lowers the user's own launches from that tree, silently degrading the toolchain inside it

[NateScarlet]

Summary

On Windows, workspace-write gives the workspace root an inheritable Low mandatory integrity label (README, Known Limitations: "A standing Low label outlives DSH and widens the tree for other Low-integrity processes"). That entry documents one consequence — other Low-integrity processes can now write inside the workspace.

There is a second consequence it does not mention: any process the user launches from inside the labeled workspace starts at Low integrity, even when the launching shell is Medium. Once a workspace is labeled, the toolchain that lives in it (uv, .venv\Scripts\python.exe, node, built executables) runs at Low. Because a Low token cannot write the security descriptor of an object that is not labeled Low, those tools silently lose the ability to modify anything outside the labeled tree.

This is distinct from the documented cost. The documented cost is the workspace becomes writable by other Low processes. This report is about the user's own Medium-integrity launches being lowered.

Environment

• Windows, NTFS volume, ordinary (non-elevated) user token
• @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-alpha.2 (the label code is byte-identical in 0.1.7-rc.1 per the hash comparison in [Bug] Windows: after upgrading to 0.1.7-rc.1 every shell command fails at the ACL grant with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)` / 升级到 0.1.7 后所有 shell 命令在沙箱授权阶段立即失败（粘性，需手工修 ACL） #7646)
• Observed both on a workspace labeled by DSH and reproduced standalone

Minimal reproduction (no DSH required)

# From a Medium-integrity shell
mkdir C:\probe
icacls C:\probe /setintegritylevel "(OI)(CI)L"
copy C:\Windows\System32\whoami.exe C:\probe\whoami_probe.exe

whoami /groups | Select-String 'Mandatory Label'                    # Medium
C:\Windows\System32\whoami.exe /groups | Select-String 'Mandatory Label'   # Medium
C:\probe\whoami_probe.exe /groups | Select-String 'Mandatory Label'        # Low

Same shell, same parent process, same working directory. The only difference is that the copied image file carries the Low label while the System32 original does not.

Observed:

launched image	image label	resulting process integrity
C:\Windows\System32\whoami.exe	(none → Medium)	Medium (S-1-16-8192)
C:\probe\whoami_probe.exe (copy)	Low (S-1-16-4096)	Low (S-1-16-4096)

The same effect on a real workspace: a shell reports Medium, but uv run python — whose interpreter lives under the workspace tree — reports Low, while a system-wide interpreter in an unlabeled location reports Medium. A live whoami (not a library call) was used for every measurement.

Mechanism: the image file's mandatory integrity label appears to participate in the new process's integrity level at creation time. I am stating that as the likely cause from the observations above; I have not verified it against Microsoft documentation.

Why this matters

1. It silently degrades the user's toolchain. Any interpreter or binary inside the workspace runs at Low. Tools that need to write outside the tree (package managers touching a global cache, anything touching %LOCALAPPDATA%, provisioning, ACL edits) start failing with Access is denied far from the original cause.
2. It is sticky and not self-healing. The workspace label is standing by design (README: "Security descriptor edits are standing directory mutations ... never revoked"), and a Low process cannot raise it back — rewriting the label with icacls <dir> /setintegritylevel Medium from the lowered process is denied (this matches the "self-healing" probe in Windows: workspace-write sandbox fails with SetNamedSecurityInfoW Win32 5 when the workspace directory DACL lacks WRITE_OWNER #7504, which found the same denial from inside the confined child).
3. It can break provisioning for unrelated directories. A Low token cannot write the SACL of an unlabeled directory. So if a shell that has been lowered this way tries to provision another directory, the combined apply fails with ERROR_ACCESS_DENIED (Win32 5) — the same signature reported in Windows: workspace-write sandbox fails with SetNamedSecurityInfoW Win32 5 when the workspace directory DACL lacks WRITE_OWNER #7504 / [BUG REPORT] Windows 沙箱无法在用户自建目录上 provision 工作区 ACE → 该目录下所有 shell 命令失败 #7538 / [Bug] Windows: `windows-acl` rung is auto-selected without a probe, but its host-side write grant always fails without SeSecurityPrivilege #7622 / [Bug] Windows: after upgrading to 0.1.7-rc.1 every shell command fails at the ACL grant with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)` / 升级到 0.1.7 后所有 shell 命令在沙箱授权阶段立即失败（粘性，需手工修 ACL） #7646, but reached by a different route. (In my case this was a third-party tool reusing this package's grant primitives; the mechanism is the one above.)

Relationship to the existing report #7504

#7504 identifies the gate for first-time provisioning as WRITE_OWNER on the directory, and documents the one-time icacls <dir> /grant "<user>:(OI)(CI)(WO)" workaround. That analysis is about a Medium-integrity host. The failure mode here is different: the host itself is Low because it was launched from a labeled tree, so no amount of DACL work on the target directory helps — the caller cannot write the SACL at all.

Open questions

• Is the lowering of the user's own launches considered part of the documented label cost, or was it not considered? README:121 enumerates only the "other Low-integrity processes" direction.
• Could the workspace label be applied without OI|CI inheritance onto executables, so the tree stays writable by the confined child but images inside it do not get lowered? (OI is needed for files created later; I do not know whether a narrower combination is viable.)
• Would a per-session revocable label (rather than a standing one) be feasible, given the stated reason it is standing — avoiding full-tree re-propagation on every provision?

---

中文要点

Windows 的 workspace-write 会给工作区根打上可继承的 Low 完整性标签。README 的 Known Limitations 只说明了一个后果：其他 Low 完整性进程因此能写入工作区。

本文报告另一个未记录的后果：用户在工作区里直接启动的任何进程都会变成 Low，即使父 shell 是 Medium。工作区里的工具链（uv、.venv 的 python、node、编译产物）全部降级；而 Low 令牌改不了未标 Low 对象的安全描述符，于是这些工具无法再修改工作区外的任何东西，且无法自行恢复（改写标签会被拒）。

最小复现不需要 DSH：把 System32 的 whoami.exe 复制到一个标了 Low 的目录，同一 shell 下原件报 Medium、副本报 Low。

与 #7504 的区别：#7504 讨论的是 Medium 宿主首次 provision 缺 WRITE_OWNER；这里宿主本身就是 Low（因为它从被标 Low 的目录启动），改目标目录的 DACL 无济于事。

[See-Sol-Lab]

Adding a data point from 0.1.7-rc.1 (the dsh-sandbox-windows-acl code is unmodified upstream; we hit it through a desktop app that embeds DSH). For us the most visible symptom was not a late Access is denied but a hard crash at startup.

What we saw

• An Electron project that DSH had written to in workspace-write mode could no longer start its own node_modules\electron\dist\electron.exe. The workspace root carried the three standing edits: S-1-4-…:(OI)(CI)(W,D,DC), Everyone:(CI)(DENY)(DC) and Mandatory Label\Low Mandatory Level:(OI)(CI)(NW).
• Even a blank app.whenReady() app exits with 0x80000003 (STATUS_BREAKPOINT): no stdout/stderr, no app log, no Crashpad directory. This happens from the user's own shell, after DSH has exited.
• The identical Electron 43.5.1 archive extracted to an unlabeled directory starts normally, and so does Electron 43.7.3 from another, unlabeled repository. A whoami.exe copied into the workspace reports Low, matching the reproduction above.
• node / pnpm live outside the tree, so builds and unit tests stay green. Only things that launch an executable from inside the workspace break, which makes it easy to misread as an Electron or environment problem.

This is different from #6544: that one is Chromium started inside the confined child; here it is the user's own launch, outside DSH, and it persists after the session.

Recovery that worked here

The README says icacls cannot revoke these edits (1332). Addressing the SIDs through .NET SecurityIdentifier worked for us; it only touches the workspace root and the children re-inherit:

$root = 'C:\path\to\workspace'
$acl = (Get-Item $root).GetAccessControl('Access')
$acl.PurgeAccessRules([Security.Principal.SecurityIdentifier]'S-1-4-<x>-<y>')  # the capability SID icacls shows on the root
$everyone = [Security.Principal.SecurityIdentifier]'S-1-1-0'
foreach ($r in @($acl.GetAccessRules($true, $false, [Security.Principal.SecurityIdentifier]))) {
  if ($r.AccessControlType -eq 'Deny' -and $r.IdentityReference -eq $everyone) { [void]$acl.RemoveAccessRuleSpecific($r) }
}
(Get-Item $root).SetAccessControl($acl)
icacls $root /setintegritylevel '(OI)(CI)M'

Afterwards electron.exe inside the tree starts again (label Medium, no capability ACE, no deny). DSH will of course re-apply all three on the next provision of that directory.

Suggestion

It would help to list "executables inside the workspace start at Low integrity; Chromium / Electron apps fail with 0x80000003" under Known Limitations, and to offer an official way to revoke a standing workspace grant, so users are not left editing ACLs by hand.

---

中文补充

我们在 0.1.7-rc.1 上遇到同一问题（dsh-sandbox-windows-acl 为上游原样代码）。最明显的症状不是事后才出现的拒绝访问，而是直接崩溃：

• DSH 以 workspace-write 写过的 Electron 项目，项目里自己的 electron.exe 再也起不来。连空白程序都以 0x80000003 退出，没有任何输出或日志。这发生在 DSH 退出之后、用户自己的终端里。
• 同一个 Electron 43.5.1 解压到没有标签的目录就能正常启动。拷进工作区的 whoami.exe 显示 Low，与上面的复现一致。
• node、pnpm 装在工作区外面，所以构建和单元测试照常通过；只有从工作区里启动的程序会坏，很容易被误判成 Electron 或环境问题。
• 与 [Bug/建议] Windows 沙箱内无法启动 Chromium 系浏览器（0x80000003）—— 根因定位与修复建议 #6544 不同：那边是在受限子进程里面启动 Chromium；这里是用户自己启动，而且会话结束后依然存在。

恢复办法见上面的 PowerShell：用 SecurityIdentifier 删掉能力 SID 授权和 Everyone 的拒绝项，再把标签改回 Medium。README 说 icacls 撤不掉，这个办法我们实测可行，改完 electron.exe 恢复正常。下次 DSH 授权同一目录时，这三项会被重新写上。

建议在已知限制里写明「工作区内的程序会以低完整性启动，Chromium / Electron 会以 0x80000003 崩溃」，并提供官方的撤销办法。

[dsh-community-assistant[bot]]

Thanks for the report.