Windows sandbox: workspace folders get a Low integrity label, so Windows treats their files as Internet-zone

[Sggin1]

What can happen
On Windows, adding a folder as a workspace (windows-acl sandbox, workspace-write) puts a Low mandatory integrity label on the folder and
propagates it to everything under it. Windows' attachment logic maps Low-labelled files to the Internet zone, so for every file in that tree:

• .lnk / .exe / .bat show "Open File - Security Warning, Unknown Publisher" when opened;
• shortcut icons render as the generic page icon.

Removing the workspace in the app does not remove the labels. A broad workspace (Desktop, user profile, a drive root) affects everything under it.

How to confirm
In a fresh PowerShell process (the zone result is cached per process):
[System.Security.Policy.Zone]::CreateFromUrl("file:///<path>").SecurityZone returns Internet for an affected file and MyComputer for a normal one.
icacls <path> shows Mandatory Label\Low Mandatory Level.
Repair: icacls <dir> /setintegritylevel "(OI)(CI)M" /T /C (needs WRITE_OWNER; on a drive where the user only has Modify it needs an administrator prompt).

Suggestion
A "release workspace" action that reverts the label, and a warning (or refusal) when the chosen folder is a drive root, the user profile or Desktop.

Windows 10 22H2, DSH 0.2.1-alpha.2 (packages/sandbox/sandbox-windows-acl).

[argszero]

The label's shape confirms why /reset cannot undo it, and the zone mapping is the mechanism behind two symptoms that were reported separately.

Three things from the source at 86a402200d (the dsh-v0.2.1-alpha.4 tree):

The label is one inheritable ACE in the SACL, no-write-up. packages/sandbox/sandbox-windows-acl/src/acl.ts:181 and :201 add it with SUB_CONTAINERS_AND_OBJECTS_INHERIT and SYSTEM_MANDATORY_LABEL_NO_WRITE_UP (bit 0x1, which icacls renders as (NW)), naming S-1-16-4096. Both halves matter here: it is inheritable, so a workspace chosen at a broad root carries it downward with no second write; and it is a SACL entry, which is why icacls <dir> /reset does not remove it — that command rebuilds the DACL and never touches the label.

The label arrives with dsh-v0.1.7-alpha.1 (commit d5ad3baeb5, "fix(sandbox): confine Windows deletes with a Low integrity label"); dsh-v0.1.6-alpha.2's acl.ts has no label writer at all. So a tree labelled by a 0.1.7-or-later build and then opened by an earlier one keeps the label. And per the same module the workspace edits are standing by design: the dispose path revokes the revocable (temp) grants and deliberately leaves the workspace ones, calling them the cross-instance reuse cache. Removing the workspace in the app therefore cannot be expected to take the label off — that is not an oversight in the removal path, it is what "standing" was chosen to mean.

Your zone finding is the mechanism behind two reports that read as separate mysteries. Distinguishing "a Low integrity label" from "an Internet zone" is exactly what was missing: this family already carries a report of msbuild / dotnet / npm refusing or warning about files as if they came from the Internet when no Zone.Identifier exists, and another of a double-clicked .exe / .cmd reporting that the publisher could not be verified. Both were carried as consequences of the label without the mapping named, so they read as unrelated one-offs. Your [System.Security.Policy.Zone]::CreateFromUrl("file:///<path>").SecurityZone probe — with the caveat that the zone result is cached per process, so it has to be a fresh PowerShell — is what turns those into something a reader can check in one command, and it adds a symptom class that had not been reported at all (.lnk icons falling back to the generic page icon).

One difference worth recording between the two repair commands now in circulation. Yours is icacls <dir> /setintegritylevel "(OI)(CI)M" /T /C. The one already measured end to end on a real tree in this family is icacls <dir> /setintegritylevel M /T, paired with backing the ACLs up first (icacls <dir> /save <file>) and removing the capability ACE through the ACL API, because icacls cannot name an S-1-4-x-y SID at all and answers ERROR_NONE_MAPPED (1332). Both leave an explicit Medium mandatory label, not the absence of a label, and both need WRITE_OWNER per object — the same right whose absence is the original failure, which is why an ordinarily Modify-only workspace cannot relabel itself without an administrator prompt, exactly as you describe.

We publish a diagnostic plugin that covers this half of the backend — npm @argszero/cordis-plugin-sandbox-grant-advisor, repo argszero/cordis-plugin-sandbox-grant-advisor. It states that the standing entries are never revoked, that the label lives in the SACL and is why /reset does not clear it, that a read-only session writes no label (so a label found after one came from an earlier workspace-write period on that directory), and it hands over a removal procedure quoted as its reporter's rather than as its own, with its three boundaries. It does not state the zone mapping or your probe, and it has no Windows host of its own behind it — which is the same standard it holds every repair command to, and the reason your thread is the measurement it would need.

[Sggin1]

Thanks, this is useful, particularly the SACL point (it explains why /reset did nothing for us) and the version boundary at 0.1.7-alpha.1.

I ran both repair commands on a scratch folder on a Windows 10 host, a normal (non-admin) prompt, a fresh PowerShell for each zone probe. The folder was on the system drive under my own profile, so I own it. The files were a .txt and a .cmd, one level down.

1. Label to zone, reproduced. icacls <dir> /setintegritylevel "(OI)(CI)L" /T /C labelled the folder and the files Low (inherited), and [System.Security.Policy.Zone]::CreateFromUrl(...) on the .cmd returned Internet with no Zone.Identifier stream.
2. icacls <dir> /setintegritylevel "(OI)(CI)M" /T /C: the folder got Medium (OI)(CI)(NW), the files Medium (I)(NW), and the zone returned MyComputer.
3. icacls <dir> /save <file> first, then icacls <dir> /setintegritylevel M /T: folder and files got a plain Medium (NW) that does not inherit, and the zone returned MyComputer. A file created afterwards had no mandatory label at all (the default). So both fix the zone; the difference is only that the first leaves an inheritable Medium on the folder.
4. Elevation: on the system drive in my own folder a normal prompt could lower and raise the label. On a second drive (default permissions give my account Modify) even lowering the label on a new folder was "Access is denied", which matches your WRITE_OWNER point.
5. Inheritance beyond the workspace: a brand-new folder created under my projects folder on that second drive inherited DSH's entries: the S-1-4-… capability SID, an Everyone: DENY (S,DC), and a Medium (NW) label. So the parent folder carries them, not only the registered workspace folders. After relabelling a tree to Medium, the S-1-4-… SID is still on the folders, as you said about icacls not being able to name it.
6. Not tested: restoring from the saved ACL file, and removing the SID through the ACL API. I did not touch any live workspace.

Two questions for the maintainers, if one of them reads this: should removing a workspace (or /reset) be able to take the label and capability entries off the folders it set them on, and could a workspace chosen at a drive root or at a broad projects folder be refused or at least warned about, given that the label inherits downward?