Boxr's rootless isolation model: user namespaces, a pre-Tokio trampoline, and no root daemon

[kchaitanya863]

I've been building Boxr, a rootless OCI container engine in Rust, and after the networking stack (Discussion #393), the piece I want to put under the microscope next is the isolation model: how a container gets "root inside, nobody outside" with no sudo, no root daemon, and no setuid binary of my own.

The core trick is boring on purpose: Linux user namespaces. The container's uid 0 maps to your unprivileged host uid. Everything that looks privileged inside the container — mounting, chrooting, creating network namespaces — is unprivileged outside it, because the kernel checks capabilities against the userns, not the host. If a container process escapes its namespaces, it's still just you.

The part that surprised me is how much ceremony it takes to get there. The kernel rejects unshare(CLONE_NEWUSER) with EINVAL from a multi-threaded process, and my main binary runs on Tokio. So main.rs intercepts a hidden __internal-trampoline subcommand before the runtime is built, and the real setup happens in a single-threaded re-exec of myself. Then there's a fork + socketpair dance:

1. The child unshares the user namespace and signals "ready".
2. The parent writes the UID/GID maps — preferably via the distro's newuidmap/newgidmap with /etc/subuid ranges, falling back to writing /proc/<pid>/uid_map directly (single mapping: container root → your uid; setgroups gets "deny" first, which the kernel requires).
3. The parent signals "done", and the child — now root-in-userns — unshares the remaining namespaces in a deliberate order: netns first (so the networking layer can attach before the PID namespace exists), then PID, mount, IPC, UTS, and optionally cgroupns. One more fork makes the grandchild PID 1.

Inside, it's the standard OCI playbook, done carefully: pivot_root (with chroot fallback), fresh proc/sys/dev (sysfs falls back to tmpfs since restricted userns often can't mount new sysfs), device nodes bind-mounted from the host, bind mounts validated with a canonicalize + starts_with escape check, generated resolv.conf/hosts. Then lockdown before exec: a seccomp-BPF filter, capability bounding-set drops for anything outside the OCI bounding set, setuid/setgid down to the spec's user, environment scrubbed. Cgroups v2 limits attach to your systemd user slice when it exists. Children get PR_SET_PDEATHSIG so nothing outlives the parent.

Honest caveats — the parts I lose sleep over:

• The entire model rests on user-namespace kernel code. A userns privilege-escalation CVE breaks this the way it breaks every rootless runtime. There's no defense in depth against the kernel itself.
• My seccomp profile is default-allow with a ~27-syscall denylist (bpf, ptrace, unshare, mount-ish, keyctl…), not Docker's default-deny allowlist. Weaker posture, less breakage risk. I haven't convinced myself which side of that tradeoff a beta should be on.
• Cgroup limits are best-effort: if the user slice isn't delegated, the writes silently fail and your --memory flag does nothing. Silent is arguably worse than failing.
• Precision on the "no setuid" claim: boxr ships no setuid helper and runs no root daemon, but it will use the distro's setuid newuidmap/newgidmap when present. The fallback path (direct /proc writes, single-UID map) uses no setuid anything. Whether the convenience of subordinate UID ranges is worth keeping setuid binaries in the trust path is an open question.

What I'd love feedback on:

1. Seccomp posture for a beta: is a default-allow denylist defensible while iterating, or should I bite the bullet and build the allowlist now?
2. Should I drop the newuidmap/newgidmap path entirely and always use the direct single-UID /proc fallback — fewer moving parts, zero setuid in the trust path — at the cost of multi-UID fidelity (think apt's _apt user)?
3. For cgroup limits under rootless: hard-fail run --memory when the hierarchy isn't delegated, or keep the current silent best-effort?

~28k lines of Rust, single maintainer, beta quality. The isolation code lives in src/runtime/linux.rs (run_trampoline) and src/security/mod.rs. Happy to walk through any of it — especially the parts above that I'm unsure about.