What Veracage defends against, how, and its documented limits. Full design in veracage-design.md, the isolation mechanism in uid-isolation.md, open findings in known-problems.md.

1. Unprivileged host processes running as the same user reading volume contents: indexers, backup daemons, thumbnailers, session malware.
2. Accidental leaks: ~/.cache plaintext, recent-files, swap of plaintext, host clipboard managers (Klipper/GPaste) scraping a sandbox copy.

The decrypted volume is unreadable to any non-root host process outside the sandbox. Files and clipboard cross the boundary only on explicit user action.

The isolation is one-directional: it keeps the host out of the volume, not the app out of the host. The app you launch is trusted, so a malicious sandboxed app is outside the threat model (see Limitations). The sandbox restrictions (no network, no host filesystem) exist to keep the decrypted data from leaking out, not to confine the app.

No setuid. The only root steps (mount/dismount and the compositor spawn) run in a small polkit-authorised Rust helper (helper-rs/). The compositor spawn execs and is gone. A mount forks: the child mounts and execs the leader in seconds, and the parent stays root as long as the session does, blocked in waitpid. It listens on nothing and reads no input, so after the fork nothing can ask it to act. It is there to close every volume in the session lock when the leader exits, which is what tears a session down when the leader is SIGKILLed (the ExecStopPost below covers the case where the helper is gone too).

The helper does not trust its caller. It is reachable by any active local user via pkexec (auth_self_keep), so:

• the target uid/gid come from PKEXEC_UID (never argv), and it refuses if unset or 0.
• the continuation it execs is pinned at build time to {_leader, _compositor}, not a caller argument.
• forwarded env vars are allowlisted (no LD_PRELOAD / LD_LIBRARY_PATH smuggling).
• it rejects unknown arguments. There is no caller-supplied mountpoint at all: the helper derives it as <workspace>/<label> from the volume's own label, through sanitize_label, which reduces the label to one safe path component.
• the --session id is bound to PKEXEC_UID (it is the caller's own uid), so a second local user can't setns/mount/close against another user's session by passing a foreign session id. veracage-cleanup enforces the same owner check.

cargo test and tests/integration/test_helper_security.py guard this contract.

• Root on the host reads everything. The dm-crypt device is kernel-global (the kernel doesn't namespace device-mapper). Deny-by-uid stores the human's own data. Inherent: a normal VM doesn't seal host root either.
• Memory can still reach the disk through swap. The temporary workspace and every app's config/cache/data live in tmpfs, and the kernel may swap tmpfs pages out; so may the decrypted volume's page cache. Veracage removes the file channels (~/.cache, recent-files, thumbnails) but cannot stop the kernel swapping. Use encrypted swap or zram if that matters to you.
• Which volume is open is not a secret, only what is in it. A same-uid process can learn that from several host surfaces Veracage does not own: /proc/<leader-pid>/mountinfo (label, mountpoint, dm device), /sys/block/loopN/loop/backing_file and the helper's /proc/<pid>/cmdline (the volume's path), polkit's own journal line for the mount, and the recent files the volume picker leaves behind (known-problems.md). Veracage avoids adding to that where it can: the dm device is named at random, the transient unit and its description carry the same hash instead of the filename, and 57-veracage.rules keeps the decrypted filesystem's label and UUID out of /dev/disk. The kernel and polkit surfaces are not ours to close.
• A file opened from the sandboxed file manager has its path in /proc while the app runs. Double-clicking a file makes the file manager spawn the handler app inside the sandbox with the path in its argv, and /proc/<pid>/cmdline is world-readable no matter which uid owns the process, which bwrap --unshare-pid does not change (the host still sees the process in its own /proc). So the name of the file being edited is readable for as long as the app is open. It leaves no record: it dies with the process, and nothing on the host stores it. Apps started from the Apps menu carry no file path at all. Inherent to handing a path to a program that takes a path.
• debug = true sends app output to the journal. The session leader passes each app's stdio through, and toolkits print file paths in their warnings, so the debug setting turns app-side paths into a persistent host record. It is off by default and is a deliberate trade for diagnosing launches (docs/debugging.md).
• No network from the sandbox, even opt-in (v1 non-goal).
• Clipboard is text-only in v1.
• Apps and the compositor render on the host GPU (/dev/dri is passed through together with the /sys/dev/char and /sys/devices metadata Mesa reads to identify the hardware, and the veracage user is in the render group). The final window pixels already reach the host compositor's GPU path for display, so this opens no new exfiltration channel, and confining the app is not a goal. The /sys binds do let the app read host device metadata (see the "Minimal host surface" row).
• A malicious sandboxed app is outside the threat model. The isolation is one-directional (host out of the volume, not the app out of the host) and the app you chose to run is trusted. What stays in scope is attacker-controlled data crossing the boundary (a hostile volume's contents reaching the compositor, and the exchange path), reviewed as such.
• Config integrity is load-bearing. A same-uid process that rewrites ~/.config/veracage/config.toml can redirect what launches. The sandbox is the barrier, not the config (see known-problems.md).
• Wayland only, single user, single workstation. Cross-volume isolation is not a goal (co-hosted volumes share one clipboard by design).

Open an issue in the tracker.