Windows 下工作区被沙箱标记成低完整性后，目录里所有文件打开都弹"安全警告"

[kiddbin]

环境：Win10 家庭版 22H2（19045.7417），DSH 桌面版 0.2.0-rc.2（desktop 档），沙箱用的是自带的 dsh-sandbox-windows-acl。

问题：某个目录只要被 workspace-write 沙箱授权过一次，目录上就会被永久加上 Low 完整性标签（icacls 能看到 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)），外加一条 Everyone 拒绝删除子项的 ACE。README 里写了这个改动是常驻的、不会撤销，这我理解，但它有个 Windows 上的副作用：

这个目录里的所有文件，包括后来新建的（会继承 Low 标签），双击打开时都会弹系统的"打开文件 - 安全警告"，提示"来自 Internet 的文件可能对你有所帮助……"。我自己手动新建一个 md，打开照样弹，日常用起来很烦。

我在这台机器上做了几组对照：

1. 同一个新建的无标记文件，放工作区目录里打开会弹，复制到桌面打开就不弹；
2. 桌面文件只用 icacls /setintegritylevel Low 加个低完整性标签（其他都不动），打开就弹；
3. 工作区里的文件只用 icacls /setintegritylevel Medium 改回正常（其他都不动），打开就不弹了。

所以触发条件就是 Low 完整性标签本身（Windows 对低完整性文件的处理跟"从网上下载的文件"一样），和 Zone.Identifier 没关系。

建议：

1. README 里能不能把这个副作用写明白些（现在只提了常驻标签，没说会导致打开文件弹安全警告）；
2. 能不能给个开关：授权时不降级令牌、不打 Low 标签（隔离弱一点可以接受），或者允许把 ACL 改动限制在一个专门的沙箱目录里；
3. 如果暂时不改，至少把缓解办法写进文档（比如用完后 icacls <目录> /setintegritylevel (OI)(CI)Medium /T 恢复，或者给文本类扩展名配 HKCU 的 LowRiskFileTypes 策略）。

谢谢。

[argszero]

Mechanism confirmed from source — plus two things your mitigation list does not yet cover

Your three-arm A/B is the right experiment (it isolates the label rather than Zone.Identifier), and your reading of the cause matches the code. Below: exactly which call stamps that label and why it inherits, why it stands by design (with the reason, which is stronger than a doc omission), two corrections to your mitigation list, and the answer to your ask #2 — which has a source-level answer, not just a policy one.

What stamps the label

packages/sandbox/sandbox-windows-acl/src/acl.ts:169-188, buildLowLabelAcl():

if (api.addMandatoryAce(
  acl, abi.ACL_REVISION, abi.SUB_CONTAINERS_AND_OBJECTS_INHERIT, abi.SYSTEM_MANDATORY_LABEL_NO_WRITE_UP, lowLabelSidPtr,
) === 0) { … }

one SYSTEM_MANDATORY_LABEL_ACE naming the Low SID S-1-16-4096 (:166), with the flags you see in icacls: SUB_CONTAINERS_AND_OBJECTS_INHERIT is your (OI)(CI) and SYSTEM_MANDATORY_LABEL_NO_WRITE_UP is your (NW). It is emitted by grantWrite() (:379-420) in one SetNamedSecurityInfoW together with the capability-SID allow ACE and the Everyone deny, and the confined token is separately lowered to Low (src/index.ts:290 → src/token.ts:148-165). The module README states the same at line 98.

The (OI)(CI) is why later files are affected: the label inherits to subcontainers and objects, so your hand-created .md carries it without anything touching the file. Your Everyone deny observation is the other half of that same call — DENY_ACCESS, FILE_DELETE_CHILD, CONTAINER_INHERIT_ACE (:412), container-inherit only, deliberately not inherited onto files (README:124).

Why it stands — and why that is not just an undocumented default

src/index.ts:34-36:

grants are standing ACE mutations on real directories. WORKSPACE grants are deliberately never revoked — the ACE is the cross-session reuse cache (revoking would force the next session to re-propagate the whole tree).

The cost being avoided is stated at acl.ts:367-368: re-propagating the identical descriptor across the tree is "eager inheritance; minutes on large workspaces". The fast path that makes re-provisioning cheap is acl.ts:379-381, and it requires all three of the exact grant ACE, the exact deny, and the exact label.

Correction 1 — clearing the label yourself does not stick

Because that fast path needs the exact label, a manual Medium reset turns the next grant of that directory into a full apply: the label comes back and the tree re-propagates. So icacls <dir> /setintegritylevel (OI)(CI)Medium /T buys you quiet until the next workspace-write run in that workspace, not permanently. Your arm 3 proves the symptom is gone; it does not prove the change survives.

(One thing worth separating, because two statements in this repo can otherwise look contradictory: the module README's "manual icacls cleanup cannot revoke them on this platform (ERROR_NONE_MAPPED, 1332), so revoke through this module" (line 128) is about the capability ACE/deny half, whose SID is the derived one. The label names the well-known S-1-16-4096, which is exactly why icacls /setintegritylevel addresses it and your arm 3 works.)

Correction 2 — there is a supported route to a revocable grant, just not one the desktop profile uses

AclWriteGrant.add(path, standing = false) (src/grant.ts:105-108, exported at src/index.ts:58) records the path as revocable when standing is false, and dispose() revokes it (grant.ts:113-121); revokeWrite() then clears the label when no other capability grant remains on that directory (acl.ts:434-446, condition documented at :330-337). So the machinery for "grant it, then take the label back" exists in the public API. The DSH seam provisions the workspace as standing for the reason quoted above — which is where your ask #1 lands: the README says the edits stand, and line 129 says the label outlives DSH and widens the tree for other Low-integrity processes, but nowhere does it connect that to the shell behaviour you measured. Your ask #1 is right and narrow, and I would put one sentence next to lines 128-129 saying that a Low-labeled root makes Windows treat its files as low-integrity at open time (i.e. the "打开文件 - 安全警告" prompt), independently of Zone.Identifier.

Your ask #2 — the source answer is worse than "no switch today"

A switch that keeps the token lowering but skips the label does not produce a weaker sandbox; it produces a workspace the sandbox can start a command in and the command cannot write to. The label rides the same SetNamedSecurityInfoW as the grant (DACL_SECURITY_INFORMATION alone appears only when the label edit is keep), and the confined token is itself lowered to Low, so the directory's Low label is precisely what lets that Low child write there under no-write-up. Removing the token lowering as well is what a community patch had to do — that gives up half the confinement, not one of two independent layers. This has been asked before; the analysis is written up with its source trail as item 6 of the README of @argszero/cordis-plugin-sandbox-grant-advisor (npm; public repo: argszero/cordis-plugin-sandbox-grant-advisor), which collects these "the error does not name the outstanding condition" cases for this backend. It is the item I would point you at for the full argument:

npm i @argszero/cordis-plugin-sandbox-grant-advisor

It repairs nothing and writes no ACL — it reads the state and tells the model, in the same step, which condition is outstanding.

What I will take from your report

Your A/B is the first measurement I have seen of the usability half of a consequence this codebase documents only on its security side. I am going to file the missing README sentence as the concrete ask, and add a read-only helper to the advisor's next release that reports, for a given directory: is the Low label present, is it inheritable, is the workspace capability grant standing, and what clearing the label would cost (label re-applied and tree re-propagated at the next grant). That turns your three manual arms into one command — and lets the next person with this question see the trade-off before deciding.