Sandbox Runtime 0.0.81

Every change in this release is on Windows. Nothing changes on macOS or Linux.

Read this first

• Run the install again. The setup version changed: a session on an earlier install rejects with reinstall_required and the command to run. The network filters also change only when the install is run. (#708, #745)
• Sandboxed commands run under a write-restricted token. The sandbox account is a member of Users, so a command could create and modify files wherever Users or Authenticated Users hold write access, whatever the allow list said. It no longer can. This is the only mode: windows.writeRestrictedToken is accepted and ignored. Schannel-based tools (the system curl.exe, .NET and PowerShell web requests) do not work under this token and have to run outside the sandbox. (#708)
• The install makes the user's profile readable to sandboxed commands, read and execute only, minus a built-in list of credential stores, as the home directory is on macOS and Linux. Tools installed in the profile run, and package managers find the user's configuration. Configuration that can hold feed tokens is readable on purpose: .npmrc, pip and NuGet config, Maven settings, Gradle properties, .gitconfig. skipProfileGrant at install, or srt-win profile forget later, leaves a working sandbox without it. The sandbox account is one per machine, so skip the grant on a shared machine. (#708)
• network.allowLocalBinding: true now means something. It opens loopback to sandboxed commands, as on macOS, and needs an install made with --allow-loopback. A session that asks for the other mode than the installed one is refused with wfp_loopback_mismatch before anything is launched. Off by default. (#745)
• Proxy variables are in the command's environment in lower case only (http_proxy, https_proxy, ...). (#739)

Fixed: the sandbox could be left

• AppContainer children. The network block matched only tokens that pass an access check for the sandbox account; an AppContainer token of that account did not, so a sandboxed process could start an AppContainer child that connected directly. (#745)
• The stdin pipe. A sandboxed command inherited the server end of its stdin pipe and could impersonate the pipe's client, the real user. It now gets a client end of a named pipe that only the launching user can open. (#724)
• Denies at session end. Deny entries were restored even when a grant could not be revoked, so a deny could come off while an allow was still on disk. They now come off only when every grant is gone or still held by another session. (#708)

Fixed: other

• Large projects. Granting a project root rewrote the ACL of every file beneath it at each session start and end. Write grants on a root are now kept between sessions: the first session in a root walks the tree once, and a later session start reads one ACL per root and writes nothing. Entries other programs wrote on a root are left as they are. (#708)
• .NET process starts. The environment held each proxy variable in upper and lower case, and .NET refuses such a block: MSBuild's compiler task, PowerShell's Start-Process with redirected output and dotnet watch failed inside the sandbox. (#739)
• Node's built-in HTTP clients (fetch, http, https) use the sandbox's proxy: NODE_USE_ENV_PROXY=1 is set with the proxy variables. A value the caller sets is kept. (#738)
• A disabled Secondary Logon service is reported by name, with the typed error seclogon_disabled, before anything is granted. The launch used to fail with an unrelated error from the network check. (#709)
• A session start does not block the event loop. The fence check and the profile status call ran srt-win synchronously inside initialize(). (#748)

New

• Profile read grant: srt-win profile grant|forget|status; grantWindowsProfileRead, forgetWindowsProfileRead{,Async}, getWindowsProfileReadStatus{,Async}, windowsProfileReadEnv and windowsProfileExclusionConflicts; SandboxManager.getWindowsProfileRead() and getWindowsProfileReadWarnings(). (#708, #748)
• Kept write grants: srt-win acl forget [... | --all [--force]] removes them; uninstall does too. (#708)
• srt-win install --allow-loopback, and allowLoopback in the library's install options. One loopback port, 1, stays blocked in either mode, so the fence check always has a target that must be refused. (#745)
• The fence check tries each token shape a sandboxed process can put on a thread, and returns what is not fenced as residuals with warnings. (#745)
• README: what the network fence does not cover (SMB, WSL, the anonymous token). (#726, #745)

For whoever upgrades

• Typed errors an embedder may want to handle: reinstall_required, seclogon_disabled (exit 18), wfp_loopback_mismatch (exit 19), profile_grant_outdated, session_ended.
• Kept grants: a kept root can be written only by a session that lists it, and read by any sandboxed session on the machine.
• Not covered by the write restriction: deleting or moving a file out of a folder where Users or Authenticated Users hold Full control, and any folder open to Everyone.
• Not fenced, and reported by the fence check instead: a connect made under the anonymous token, or under a copy of the command's token with the user SID deny-only. See the README's known limitations.
• Environment: a script on the MSYS2 runtime that reads only the upper-case $HTTP_PROXY no longer finds it. Native Windows programs find either spelling.
• Exports: thirteen added, none removed. ISandboxManager has two new members, getWindowsProfileRead and getWindowsProfileReadWarnings.