Running an untrusted OCI image

When the image comes from someone you do not trust, the goal is to grant the workload the least it needs and nothing more. This guide covers the posture for running a hostile OCI image.

Start strict, loosen deliberately

ZViz applies a default enforcement stack — five namespaces, all 41 capabilities dropped, Landlock, seccomp, cgroups v2. For untrusted work, start from the strictest profile and widen only where the workload fails for a legitimate reason:

zviz run untrusted ~/bundle --profile hostile-tenant

Deny network by default

Egress is default-deny. A workload that should never phone home simply cannot. When a workload legitimately needs the network, grant the specific access it requires rather than opening egress wholesale.

Constrain the filesystem

The Landlock ruleset limits which paths the workload can read and write. Mount in only the directories the workload needs, read-only where possible. ZViz auto-mounts /proc (nosuid+nodev+noexec), /sys (read-only), and a private /dev tmpfs, so you do not need mounts[] entries for those.

Verify what is blocked

Dangerous syscalls return EPERM. If the workload tries ptrace, mount, unshare, or init_module, it is denied at the seccomp boundary before the kernel runs the call. Run with --verbose to see the allow/deny decisions as they happen.

When a workload does not fit

If the image genuinely needs ptrace, mount, unshare, or nested containers, ZViz will block it by design. That is a signal to run it under gVisor instead, which emulates those syscalls. See the threat model for where ZViz’s boundary sits.