You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: isolate /run with tmpfs and recreate /var/run symlinks in sandbox (#54)
* fix: isolate /run with tmpfs to prevent sandbox escape via host sockets
Previously, buildDenyByDefaultMounts bind-mounted the entire host /run
read-only, then overlaid /run/user with a tmpfs for D-Bus isolation.
This left host sockets (Docker, Podman, containerd, libvirt, etc.)
accessible inside the sandbox. Unix socket connections bypass
filesystem read-only restrictions, so any exposed socket with
matching permissions allowed full sandbox escape (e.g., docker run
with host filesystem mounts).
Replace the blanket --ro-bind /run /run with --tmpfs /run (allowlist
approach), selectively mounting only:
- /run/systemd/resolve/* when /etc/resolv.conf is a symlink into /run
- /run/user/<uid>/bus for the filtered D-Bus proxy socket
This matches the existing SSH key protection pattern (--ro-bind
/dev/null over sensitive files) but is more robust: unknown sockets
are excluded by default rather than requiring explicit deny rules.
* fix: recreate /var/run and /var/lock symlinks in sandbox
On modern Linux distros, /var/run is a symlink to /run and /var/lock
is a symlink to /run/lock. Many programs (virsh, systemctl, etc.)
hardcode /var/run paths.
The sandbox already recreates symlinks for /bin, /sbin, /lib, /lib64
but was missing /var, causing programs to fail with "No such file or
directory" even when /run paths were correctly configured.
Fixes#53
0 commit comments