workspace-write leaves a persistent Low integrity label on the workspace root, breaking installers launched from that folder

[BoogonClothman]

Summary

Using a broad user folder (e.g. C:\Users\<user>\Downloads) as the workspace in workspace-write mode causes the Windows ACL sandbox to apply its standing security descriptor to that folder, including an inheritable Low integrity label. The label survives the session and propagates to files created later. Any executable launched from that folder then runs at Low integrity (measured: Low, 0x1000) and cannot write to the Medium-integrity %TEMP%, so NSIS installers fail with:

Error writing temporary file. Make sure your temp folder is valid.

The same executable copied to a normal folder runs at Medium integrity (0x2000) and works normally.

Environment

• DSH 0.2.1-rc.2 (desktop, nightly)
• Windows 11 26H2, 10.0.26300.9711
• sandbox mode workspace-write
• package @deepseek-ai/dsh-sandbox-windows-acl

Reproduction

1. Start a session with cwd C:\Users\<user>\Downloads in workspace-write (observed: session of 2026-10-17, title "ScholarTools.exe malware analysis").
2. Run any confined command so the sandbox provisions.
3. End the session. The folder keeps:

S-1-4-352691444-216974905:(OI)(CI)(W,D,DC)
Everyone:(CI)(DENY)(DC)
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

4. Download install-tl-windows.exe into that folder (the new file inherits the Low label).
5. Double-click it -> NSIS error above.

Process integrity level, same file / same user / same TEMP:

Launched from	Token IL	Result
C:\Users\<user>\Downloads	Low (0x1000)	NSIS error
C:\TempFix (copy)	Medium (0x2000)	installer starts

Additional check: the failing process's own environment has TEMP=C:\Users\<user>\AppData\Local\Temp (the normal path), and a write probe to that folder succeeds at Medium integrity. The temp path is valid; only the integrity mismatch fails.

Expected behavior

• Do not leave a permanent Low label on the user-selected workspace root after the session, or
• restrict the label to a sandbox-private/shadow root, or
• provide a supported cleanup path (manual icacls may hit ERROR_NONE_MAPPED 1332 when removing the S-1-4-… ACE).

Root cause

As documented in the backend README:

"A standing Low label outlives DSH and widens the tree for other Low-integrity processes … any other process running at Low integrity as the same user … can write and delete inside the workspace."

"Diagnosis preserves integrity labels — it cannot fix Low-labeled executables affecting programs launched outside DSH."

That trade-off is reasonable for a dedicated project workspace, but when the workspace is a mixed-content folder such as Downloads, Desktop, or the user profile, it silently downgrades ordinary host programs. The failure surfaces inside an unrelated installer, so users cannot connect it to DSH.

Impact

• NSIS/Inno and similar installers launched from that folder fail.
• New files keep inheriting the Low label; the problem is persistent and survives a DSH uninstall.
• Everyone:(DENY)(DC) also affects deletes through the parent directory.

Suggestions

1. Revoke the root label on dispose, at least for broad folders (Downloads, Desktop, profile, drive roots) — possibly deferred/background to avoid re-propagating the tree on every provision.
2. Do not label the user-selected root directly; use a sandbox-private shadow root.
3. Add dsh sandbox cleanup <path> (or fix the diagnosis skill) to remove the S-1-4-… ACE, the Everyone:(DENY)(DC), and the Low label, handling ERROR_NONE_MAPPED.
4. Warn in the UI when a broad folder is selected as the workspace.
5. Document the workaround and the label propagation.

Workaround

Copy the installer out of the folder before running it. To repair the folder (admin PowerShell):

icacls "C:\Users\<user>\Downloads" /reset /T /C
icacls "C:\Users\<user>\Downloads" /setintegritylevel "(OI)(CI)Medium" /T /C

[PerryLink]

The label surviving the session is deliberate, not a missed cleanup, and the design comment says so outright. packages/sandbox/sandbox-windows-acl/src/grant.ts:21-31:

Workspace paths are added STANDING (their security descriptor edits are the cross-session reuse cache and outlive the grant — dispose() skips revoking them, or the next provision would re-propagate the whole tree); temp paths are revocable (dispose() revokes them — an inheritable ACE must not outlive its session's temp directory).

:101-107 repeats it on add(path, standing = false). So the Low Mandatory Level:(OI)(CI)(NW) entry you measured on Downloads is the reuse cache working as written.

What is not obviously intended is the blast radius. The standing edit is a root edit with object and container inheritance, so everything created under that folder afterwards inherits Low — including an executable the user downloads days later, and then the files that executable writes. The cache is justified as "this directory is a workspace for this user", but its effect outlives that claim and applies to unrelated files. That is the gap worth reporting: not "you forgot to revoke", but "the cache is keyed to a directory that can be general-purpose".

Dropping inheritance is not a fix, which is probably why nobody has done it: the confined child runs at Low with no-write-up, so a file created in a Medium directory would be unwritable by the very process that created it. (OI)(CI) is load-bearing for the child's own writes. Turning it off moves the problem from after the session into during it.

The options I can see, none free:

• Refuse or warn at admission when the grant root is a generic user-content folder (Downloads, Desktop, Documents, the user profile root). Same shape of check as the FAT-volume posture the README already discusses, and cheap to implement because it only looks at the spelling.
• Record the pre-grant label for the standing paths and restore it on dispose. That is the cost the comment is explicitly avoiding, but it is now a known cost with a measured consequence.
• Keep the cache but move the Low-labeled tree one level down: the grant root stays a normal folder and the confined tree lives in a per-workspace subdirectory, so nothing outside that subtree inherits.

Your NSIS failure follows from the mechanism rather than from the installer: a Low process writing to a Medium %TEMP% is a write-up, which mandatory integrity policy denies before any file-system permission is consulted. The same exe at Medium integrity is the control you already ran.

[travis5207]

补充同一根因下的第二种症状——这一种连一句报错都没有。

环境与本帖一致：DSH 0.2.1-rc.2（桌面版），Windows 11 26H2 10.0.26300.9711，workspace-write。工作区根目录是一个普通项目文件夹，里面有个 .bat 启动本地 Python HTTP 服务（端口 7861），启动完调用 webbrowser.open 打开本机地址 http://127.0.0.1:7861/ 。

现象：服务本身完全正常（端口可监听、接口可用），但浏览器就是不出现——没有窗口、没有报错、没有弹窗，而 webbrowser.open() 返回 True。把地址手动粘进浏览器一切正常。

原因：工作区根目录带 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)。根目录上没有 I，说明是直接设置在该目录上的，子项靠继承。于是从这个目录树里启动的任何 exe 都以 Low 运行。Chromium 系浏览器启动时要拉起崩溃上报进程 crashpad，这一步是「向 Medium 对象写入」，mandatory 策略在任何文件权限判断之前就拒了：

crashpad_client_win.cc:430] OpenProcess: 拒绝访问。(0x5) crashpad_client_win.cc:144] crash server failed to launch, self-terminating

浏览器随即立刻退出：Chrome 2147483651（0x80000003，STATUS_BREAKPOINT）、Edge 21。Chrome 155.0.8059.80、Edge 155.0.4283.62、第三方 Chromium 内核浏览器（豆包 147.0.7727.149，作为系统默认浏览器）三者都复现。

对照实验：

· 同样的 exe 从无标签目录（D:\、%APPDATA%）启动 → 完全正常；

· 同一个工作区执行 icacls "<工作区路径>" /setintegritylevel (OI)(CI)M 之后 → 立刻恢复；

· 标签在 DSH 完全重启后没有回贴（约 20 分钟后用 SACL 直读复查确认）。

给设计讨论的两点补充：

第一点，影响面比安装器更宽。Electron 应用、Playwright/Selenium 拉起的浏览器、以及任何「启动后自动开页面」的脚本都会以同样方式失败——而且是静默失败，用户会先怀疑自己的程序、浏览器或杀毒软件（我们为此花了约 4 小时，排除了 6 个错误假设才去读 SACL）。

第二点，行为实验在这里会骗人。有效完整性级别 = min(父进程令牌, 对象标签)，所以一个 High/Medium 的父进程会掩盖 Low 标签，子进程看起来完全正常。只有直接调 GetNamedSecurityInfoW(..., LABEL_SECURITY_INFORMATION) 读 SACL 才可靠。

最小复现：在工作区里放一个 .bat，启动任意 HTTP 服务并调用 webbrowser.open()，页面不会出现；把同一个 .bat 复制到 D:\ 根目录再跑，页面正常出现。

如果对诊断路径有用，我可以提供那段读取 LABEL ACE 的 ctypes 代码（约 60 行，仅标准库）。

[hongshuxifan321]

Adding a second broad-folder datapoint, plus three things that may save others time.

Scale (Desktop as workspace; 26H2 build 26300.9711; DSH 0.2.1-rc.2): the root got Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) together with the standing S-1-4-...:(OI)(CI)(W,D,DC) and Everyone:(CI)(DENY)(DC). icacls /T counted 16028 labelled objects (13367 files + 2797 directories, including several git repos). Same NSIS failure: Error writing temporary file. Make sure your temp folder is valid.

1) Running as administrator does not work around it. Elevation raises the token to High, but the process is still capped at Low by the image's own mandatory label, so the installer fails identically (measured: same exit code). The same exe copied to a Medium directory installs fine, exit code 0. This is the first workaround most users try, so it is worth stating explicitly.

2) Repair that worked on the whole tree, without /T:

icacls "<dir>" /setintegritylevel (OI)(CI)M

Since the Low entry is inherited, changing the root label is propagated by Windows to every child - 16028 objects fixed in one call; afterwards icacls <dir> /T /Q reports 0 x Low Mandatory Level.

3) Removing the leftover S-1-4-... ACE: icacls "<dir>" /remove:g "S-1-4-..." is a silent no-op here - it prints Successfully processed 0 files; Failed processing 0 files and the ACE is still listed (same with the *SID form), which matches the ERROR_NONE_MAPPED note above. What did work:

$acl = Get-Acl -LiteralPath "<dir>"
$acl.Access | Where-Object { $_.IdentityReference.Value -eq 'S-1-4-...' } |
  ForEach-Object { $acl.RemoveAccessRuleSpecific($_) | Out-Null }
Set-Acl -LiteralPath "<dir>" -AclObject $acl

4) Not contamination: C:\$Recycle.Bin and D:\$RECYCLE.BIN also carry Low:(OI)(CI)(IO)(NW) on a normal machine - that is the OS default, so don't chase it while cleaning up.

On the design question: the standing-edits cache is intentional, but when the workspace is a broad user folder (Desktop, Downloads) every later download/installer there is silently crippled and there is no supported undo. A sandbox-private shadow root, or a documented dsh sandbox reset <path>, would close this.