Threat model
ZViz is built for one assumption: the code inside the container is the adversary. It may hold arbitrary userspace capabilities within its namespace, may attempt any syscall, and may actively try to escape. The design is an explicit bet that shrinking the reachable kernel surface is enough to contain that adversary for most workloads — while keeping native syscall speed.
In scope
- ✓ Code inside the container attempting any syscall, including dangerous ones
- ✓ Attempts to load kernel modules, escalate capabilities, or escape namespaces
- ✓ Filesystem pivots via writeable paths (constrained by Landlock)
- ✓ Fork bombs and resource exhaustion (constrained by cgroups v2)
- ✓ Unsolicited network egress (default-deny per container)
Out of scope
- ✗ Vulnerabilities in the host kernel itself along an allowed syscall path
- ✗ Side-channel and hardware attacks (Spectre-class, rowhammer, etc.)
- ✗ Workloads that require ptrace, mount, or unshare inside the container
- ✗ Threats where a hardware-virtualized (VM) boundary is a hard requirement
Where ZViz sits on the isolation curve
Isolation is a spectrum, and every point trades strength against footprint and compatibility:
- runc — namespaces + cgroups, large reachable surface. Assumes a friendly workload. Compare
- ZViz — namespaces + zero caps + Landlock + selective-denial seccomp, on the host kernel. Small surface, native speed, no guest kernel.
- gVisor — a userspace kernel emulates the ABI, so the host kernel runs fewer syscalls, at an emulation cost. Compare
- Firecracker — a hardware-virtualized MicroVM with its own guest kernel. Strongest boundary, largest footprint. Compare
Threat-model FAQ
Is ZViz as strong as a virtual machine?
No. A MicroVM like Firecracker adds a hardware-virtualized boundary and a guest kernel, isolating the workload from the host kernel entirely. ZViz shares the host kernel for allowed syscalls. ZViz is a smaller-footprint bet: shrink the reachable surface enough that a strict syscall policy is sufficient for the workload. If you need VM-grade isolation, use a MicroVM.
What happens if there is a kernel CVE?
If the CVE is in a syscall ZViz denies, the exploit cannot reach it — the syscall returns EPERM before any kernel code runs. If the CVE is in one of the 132 allowed syscalls, that risk is shared with the host, because ZViz runs allowed syscalls on the host kernel. This is the explicit trade-off of the selective-denial design.
Why require Linux 5.13+?
ZViz uses the Landlock LSM for unprivileged, kernel-enforced filesystem access control, which landed in Linux 5.13. Without Landlock, ZViz falls back to weaker chdir-only filesystem isolation.