finsafe version
0.9.42
Platform
- Windows 11 Pro, build 26200 (NT 10.0.26200.9168)
finsafe probe highlights: appcontainer_works=true, helper_installed=false, conpty_present=true
Component
Personal CLI — finsafe visual-sandbox (File vault tab, sandbox-on side; policy generation)
Steps to reproduce
- Start the UI:
finsafe visual-sandbox --port 8787
- Open
http://127.0.0.1:8787, go to the File vault tab.
- Pick a preset target and click Run comparison.
- Observe the sandbox-on side.
Expected behavior
The UI-generated wrapper policy should be schema-valid (the local-wrapper schema requires filesystem.read_only_paths), the sandbox should start, and the deny-read rule on vault\** should be included so the File vault demo actually blocks reads of the sample PII files.
Actual behavior
1) Sandbox side fails to start — generated policy is missing a required field
Error shown in the UI:
The sandbox could not start
This is a configuration problem, not a policy decision — nothing was blocked or allowed.
finsafe: policy load error at filesystem: filesystem: missing field `read_only_paths` at line 24 column 3
(C:\Users\xuls2\AppData\Local\FinSAFE\hermes\tmp\finsafe-visual-sandbox-policy-LpqnWv\wrapper.yaml:23:1)
The generated policy (...\finsafe-visual-sandbox-policy-LpqnWv\wrapper.yaml), verbatim:
# Generated by FinSAFE visual sandbox from the on-screen controls.
# Every rule below came from a UI control — nothing is hardcoded.
schema_version: 1
kind: local-wrapper
program_mode: short-lived
degrade:
allow_fallback: false
audit:
require_policy_digest: true
require_resolved_posture: true
stdio:
mode: capture
# Offline: no egress at all.
network: none
resources:
memory_max: "2G"
pids_max: "512"
cpu_max: "100000 100000"
timeout_ms: 15000
filesystem:
read_write_paths:
- "\\\\?\\C:\\Users\\xuls2\\AppData\\Local\\FinSAFE\\hermes\\tmp\\finsafe-visual-sandbox-kit"
# ignored (no writable root contains it): \\?\C:\Users\xuls2\AppData\Local\FinSAFE\hermes\tmp\finsafe-visual-sandbox-kit\vault\**The filesystem: block contains only read_write_paths; read_only_paths is absent, which the policy loader rejects (missing field read_only_paths). This is a code-generation bug in the UI's YAML emitter — the emitted document does not satisfy the local-wrapper schema — not a policy/authorization decision.
2) The deny-read rule for vault\** is silently dropped
The generated policy's own comment shows the File vault's core deny rule was discarded:
# ignored (no writable root contains it): \\?\C:\Users\xuls2\AppData\Local\FinSAFE\hermes\tmp\finsafe-visual-sandbox-kit\vault\**
Consequences even if (1) is fixed: the sandbox-on side would contain no deny-read rule, so the demo would not actually block reads of the sample salary/PII files — the File vault comparison would show a false "blocked" result.
Additional context
- The deny-read target (
vault\**) lives directly under the declared writable root (...\finsafe-visual-sandbox-kit), so it should be contained; the "no writable root contains it" verdict suggests the containment check mishandles the \\?\ extended-length path prefix and/or the ** glob.
- Env note: the kit path in this capture is under
C:\Users\xuls2\AppData\Local\FinSAFE\hermes\tmp\... because the launching shell redirected TEMP/TMP/TMPDIR there; visual-sandbox places its kit under the process temp dir, so the same bug reproduces with any kit location (default %LOCALAPPDATA%\Temp\finsafe-visual-sandbox-kit also observed).
- The sandbox-off side of the same action runs but with a wrong command path — reported separately.
finsafe version
0.9.42Platform
finsafe probehighlights:appcontainer_works=true,helper_installed=false,conpty_present=trueComponent
Personal CLI —
finsafe visual-sandbox(File vault tab, sandbox-on side; policy generation)Steps to reproduce
finsafe visual-sandbox --port 8787http://127.0.0.1:8787, go to the File vault tab.Expected behavior
The UI-generated wrapper policy should be schema-valid (the local-wrapper schema requires
filesystem.read_only_paths), the sandbox should start, and the deny-read rule onvault\**should be included so the File vault demo actually blocks reads of the sample PII files.Actual behavior
1) Sandbox side fails to start — generated policy is missing a required field
Error shown in the UI:
The generated policy (
...\finsafe-visual-sandbox-policy-LpqnWv\wrapper.yaml), verbatim:The
filesystem:block contains onlyread_write_paths;read_only_pathsis absent, which the policy loader rejects (missing field read_only_paths). This is a code-generation bug in the UI's YAML emitter — the emitted document does not satisfy the local-wrapper schema — not a policy/authorization decision.2) The deny-read rule for
vault\**is silently droppedThe generated policy's own comment shows the File vault's core deny rule was discarded:
Consequences even if (1) is fixed: the sandbox-on side would contain no deny-read rule, so the demo would not actually block reads of the sample salary/PII files — the File vault comparison would show a false "blocked" result.
Additional context
vault\**) lives directly under the declared writable root (...\finsafe-visual-sandbox-kit), so it should be contained; the "no writable root contains it" verdict suggests the containment check mishandles the\\?\extended-length path prefix and/or the**glob.C:\Users\xuls2\AppData\Local\FinSAFE\hermes\tmp\...because the launching shell redirectedTEMP/TMP/TMPDIRthere; visual-sandbox places its kit under the process temp dir, so the same bug reproduces with any kit location (default%LOCALAPPDATA%\Temp\finsafe-visual-sandbox-kitalso observed).