Frequently Asked Questions
Setup, permissions, and security tradeoffs.
User Namespaces and Kernel Attack Surface
Q1Containers can also run unprivileged. Why choose Sandlock?
Unless you opt into UID/GID mapping, Sandlock runs without CAP_NET_ADMIN, on the host or in a user namespace. CVE-2026-53075 shows why: creating a user namespace let an unprivileged user gain that capability and wrongly administer PPP in an inherited network namespace. Without that capability, this path was blocked. Other kernel risks remain.
Q2How else does Sandlock reduce attack surface compared with containers?
With its supervisor enabled, Sandlock synthesizes selected /proc files and NETLINK_ROUTE replies, blocks sensitive /proc and /sys paths, and rejects other netlink protocols. This keeps workloads away from kernel interfaces that containers may still expose, beyond avoiding CAP_NET_ADMIN. The exact comparison depends on the container’s policy.
Running Sandlock Inside Docker
Container setup, seccomp restrictions, and required capabilities.
Q3Why run Sandlock inside a container?
Use a container when your platform requires one or you want another isolation layer. Sandlock runs on its own; for just a container filesystem, use --image or --chroot.
Q4Does Sandlock work in a stock Docker container?
With the supervisor, Docker’s default seccomp profile blocks pidfd_getfd. Add SYS_PTRACE or explicitly allow that syscall in the profile. Supervisor-free mode needs neither change.
Q5Why does pidfd_getfd fail after sandlock check passes?
sandlock check checks kernel support. The container’s seccomp policy can still block pidfd_getfd at runtime.
Q6How do I run Sandlock inside Docker?
Add SYS_PTRACE: docker run --cap-add SYS_PTRACE <image> sandlock run …. This lets Docker’s default seccomp profile permit the supervisor’s pidfd_getfd calls.
Q7Can I restrict the workload after adding SYS_PTRACE?
Yes. Use --extra-deny-syscall for ptrace, pidfd_getfd, process_vm_readv, and process_vm_writev. The supervisor remains unaffected. These syscall restrictions do not drop the capability itself.
Q8Can I avoid adding SYS_PTRACE?
Yes: use --no-supervisor. You retain Landlock and syscall filtering, but lose IP allowlisting, HTTP ACLs, resource limits, copy-on-write, chroot mediation, /proc virtualization, and custom handlers. See Architecture.
Q9What about Podman and Kubernetes?
If their seccomp profile has the same gate, add SYS_PTRACE: use --cap-add SYS_PTRACE in Podman or securityContext.capabilities.add: ["SYS_PTRACE"] in Kubernetes. The requirement depends on the active profile.
Ask on the Issue Tracker
Ask a question or report a problem on GitHub.