[Bug] Windows 11 sandbox bug: real folder permissions and the Low integrity label are permanently rewritten, with no revoke path —— Windows 11 沙箱 bug：真实目录的权限与 Low 完整性标签被永久改写，且无回收路径

[Czerror]

Note: this repository has Issues disabled, so this report is filed as a Discussion.

Summary

Deleting a workspace from the client does not withdraw the security-descriptor edits the Windows sandbox made to that directory. The capability-SID allow ACE, the Everyone FILE_DELETE_CHILD deny, and the inheritable Low integrity label all stay on disk after the workspace is gone.

The orphaned Low label makes Windows' shell classify the whole folder tree as the Internet zone, so Explorer warns on every file the user opens inside it:

Your Internet security settings prevented one or more files from being opened.

Adding the workspace and running anything under workspace-write writes those three edits; one SetNamedSecurityInfoW call carries all of them. Removing the workspace is the last moment DSH still knows the directory, and the client removes the registration without undoing any of the edits.

Why nothing undoes it

The delete path never reaches the sandbox:

• packages/client/ui-workspace/src/client/index.ts: deleteWorkspace: async (workspaceId) => { await workspaces.delete(workspaceId) }
• packages/api/workspace-controller/src/commands.ts: delete() calls ctx.workspaceRegistry.delete(...)
• packages/workspace/workspace/src/index.ts: delete() is documented as "Delete one workspace registration while retaining its directory and every session log"
• packages/workspace/workspace/README.md: "Removal never deletes data — removing a project leaves its folder, files, and session histories in place"
• searching sandbox|acl|grant|integrity under packages/workspace returns nothing

The sandbox side has no other window to do it:

• packages/sandbox/sandbox-local/src/index.ts revokes grants only from the provider's own dispose effect (ctx.effect), and only revocablePaths (the private temp dir).
• packages/sandbox/sandbox-windows-acl/src/grant.ts: add(path, standing) puts the workspace root in standingPaths; dispose() never touches them.
• packages/sandbox/sandbox-windows-acl/src/acl.ts: grantWrite() applies the allow ACE, the deny, and the Low label together; revokeWrite() removes only the capability SID's ACEs.

The data-preservation contract covers the user's files, not DSH's own security-descriptor edits, and no other layer claims them. They outlive the workspace registration, the session, and the provider process.

The workspace SID is derived deterministically from the canonical workspace path (workspaceWriteSid), so the delete path could re-derive it and revoke exactly these three edits. The information is available; the step is not implemented.

Reproduction (client)

1. Add a folder as a workspace and run anything under workspace-write in it. Even a command that fails is enough, because the grant lands before the runner spawns.

2. icacls <workspace> shows the label on the root, inherited by every child directory:

   Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
   

   plus Everyone:(CI)(DENY)(DC) and S-1-4-<a>-<b>:(OI)(CI)(W,D,DC).

3. Remove the workspace from the client.

4. icacls <workspace> still lists all three entries. Nothing in the UI mentioned them.

5. In Explorer, double-click a file anywhere in that tree. A file created years before DSH is enough. The popup above appears.

6. icacls <workspace> /setintegritylevel Medium stops the popup and flips the zone decision from 3 to 0.

Evidence: the orphaned label is what the shell reads

Measured on Windows 11 26H2 (build 26200) by hooking the path urlmon!MapUrlToZone takes:

• urlmon!MapUrlToZone → urlmon+0x6F712 indirect call → iertutil+0x45890
• that function does CreateFileW → GetKernelObjectSecurity(..., 0x10 /* LABEL_SECURITY_INFORMATION */) and returns (DWORD > 0x1000)
• Low-labelled directory: 48-byte descriptor, DWORD 0x1000 ⇒ returns 0 ⇒ urlmon+0x6F755 writes zone 3
• unlabelled directory: 20-byte descriptor, DWORD 0x2000 ⇒ returns 1 ⇒ zone 0
• 13/13 paths, zero counterexamples. AreAccessRulesProtected, the SDDL P/AI flags, and SECURITY_DESCRIPTOR.Control were each measured and are not the input, since a zone-3 and a zone-0 directory carry the same value.

Observed residue on the reporting machine

Two directories that had been workspaces at some point:

workspace	capability SID (from workspaceWriteSid(path))	observed
A (no longer in the workspace registry; its sessions are in the archive set)	S-1-4-915225578-286341460	deny + allow ACE + Low label were all still present on disk; ACL and label were later cleaned by hand
B (later removed from the client's workspace list)	S-1-4-421311035-171160915	all three edits. The label was reverted to Medium by hand, then re-labelled Low by a later workspace-write grant, because a grant rewrites all three edits and silently overrides a manual fix. Once the workspace was removed, all three were finally withdrawn by hand — but the capability ACE needed the .NET object model (Get-Acl / RemoveAccessRule / Set-Acl): icacls /remove:g *S-1-4-… reports Successfully processed 0 files, exactly the mapping failure the package README warns about

Directory A is the case this report is about. The workspace was gone from DSH, but the label it left behind kept the whole tree classified as the Internet zone. The popup it produced was tracked for weeks as a Windows/shell mystery before being pinned to the label.

Together the two cases leave the user no supported way out. Keep the workspace and the next workspace-write run re-labels the tree. Delete the workspace and the edits are orphaned: nothing in DSH will ever revoke them, and the shipped recovery path treats the deny as expected rather than as something to remove. The cleanup described above was hand-rolled, and even then needed a different tool than the one the package README recommends for this class of edit. One more registered workspace on the same machine carries the same label, and no DSH surface has told the user.

Secondary finding: the deny has no removal path at all

• acl.ts revokeWrite() merges only a REVOKE_ACCESS entry for the capability SID and optionally clears the label. No code path removes the world-SID deny.
• The deny also survives a downgrade to read-only. The restricting SID list drops the capability SID, so the allow ACE goes inert, but the deny stays effective for every process, because it is an ordinary DACL entry and not a token-scoped one.
• The shipped diagnose-windows-sandbox-acl skill documents that deny as expected ("DSH's S-1-4-* grants and the Everyone DeleteSubdirectoriesAndFiles deny are expected, not conflicts"), so the supported recovery path will not remove it either.
• The same edit removes the ambient "delete a child through its parent" right that a restricted token relies on, so a restricted process whose own SID carries no DELETE on the object cannot delete it. The package README records this consequence. A normally privileged process is unaffected, because the object DACL still grants it DELETE. This class of failure is easy to misattribute.

Why it matters

• The user asked for a sandbox, not for a security-label change on a real folder. DSH never says it happened, and undoing it requires knowing icacls /setintegritylevel Medium.
• Standing grants work as a reuse cache while the workspace exists. Deleting the workspace ends that need, so the edits stay behind with nothing using them.
• The label inherits with OI|CI, so it covers files DSH never touched. One measured workspace had 84 child directories carrying it.
• A folder that behaves normally before DSH, then starts producing an Internet-zone popup, is hard to attribute. Pinning it to the label took a long reverse-engineering effort here.

Suggested directions (maintainer's call)

1. Revoke the standing workspace grant on workspace deletion. The path is known, the SID is re-derivable, and the delete is already an async durable operation. It can be best-effort and logged instead of blocking the deletion.
2. Provide an explicit recovery path for edits that already leaked: label, deny, and capability ACE for a given path.
3. Tell the user once per workspace. On the first grant, report what changed on disk and how to undo it.
4. Reconsider which object carries the label. The private temp dir needs it. If the confined child only needs the workspace root writable, a non-inheriting label, or one applied deeper, would stop the effect from reaching unrelated pre-existing files.

---

中文摘要

从客户端删除工作区，不会撤销 Windows 沙箱写进该目录安全描述符的三项改动：能力 SID 允许项、Everyone 的 FILE_DELETE_CHILD 拒绝、可继承的 Low 完整性标签。删除之后 packages/workspace 不再认识这个目录，沙箱侧也只在 provider dispose 时回收 temp 授权，三项成为孤儿残留。delete() 的契约是"只删注册、保留目录与会话数据"，而这三项既不是注册，也不是目录数据，没有任何一层认领。

Low 标签会继承到整棵树，让 Windows shell 把该目录判成 Internet 区域（zone 3）。实测判定链是 urlmon!MapUrlToZone → iertutil+0x45890，读的正是目录完整性标签，13/13 零反例；改回 Medium 后弹窗消失、判定回到 zone 0。本机有一个实例：某目录早已不在工作区注册表里（其会话进了归档集），标记却留在磁盘上，后续被当作"Windows 的怪问题"排查了很久。

那条 Everyone 拒绝在源码里没有任何删除路径，降到 read-only 也照样对所有进程生效。它还移除了受限令牌依赖的"凭父目录删除子项"这条退路（README 已记录该后果），普通全权进程不受影响。这类故障因此极易被误判成"工具坏了"。

工作区 SID 按规范路径确定性派生，删除时完全有能力反算并撤销，缺的只是这一步。建议：删除工作区时回收（可尽力而为、失败只记日志）、为已泄漏的标记提供显式回收途径、首次授权时告知用户改了什么、把标签从工作区根目录上移开或去掉继承。

[Aliya-xiaomo06]

Thanks for the detailed investigation! My desktop shortcuts were showing blank white icons, and rebuilding the icon cache didn’t help. Restoring the desktop folder’s integrity level from Low to Medium fixed all 25 affected shortcuts. Your findings helped identify the real cause. Really appreciate you documenting this!