Chromium's sandboxing code, design documents, etc. are a good read for one of the most widely deployed and battle tested windows sandboxes, and is presumably BS

Chromium's sandboxing code, design documents, etc. are a good read for one of the most widely deployed and battle tested windows sandboxes, and is presumably BSD 3-Clause "New"/"Revised" Licensed like the rest of Chromium: https://github.com/chromium/chromium/blob/main/docs/design/sandbox.md https://github.com/chromium/chromium/blob/main/docs/design/s... https://github.com/chromium/chromium/tree/main/sandbox/win/src https://github.com/chromium/chromium/tree/main/sandbox/win/s... https://github.com/chromium/chromium/tree/main/sandbox https://github.com/chromium/chromium/tree/main/sandbox Chromium's unveil equivalent on windows is to: 1. Have an "unsandboxed" broker/parent process that implements unveil-like logic for whitelisting files. 2. Have the sandboxed child process run under a heavily restricted access token that blocks "all" file I/O (except, null security FAT32 mounts are sadly still accessible). 3. Intercept/patch Win32 API calls to request whitelisted things via IPC with the broker process that would otherwise be blocked by the restricted access token. Bazel/Make are in slightly trickier situations, in that they run third party binaries - which might require shenannigans involving injecting DLLs, or creating patched EXEs, to do the intercepting/patching of `CreateFile` etc.