Software Sandboxing: The Basics

Software sandboxing is framed as discretionary, programmatic dropping of a process's privileges without requiring administrative authority. Traditional UNIX permission models and tools like setuidgid are a poor fit for application-level sandboxing, so modern practice leverages kernel-provided interfaces such as FreeBSD Capsicum, Linux seccomp, and newer mechanisms like Landlock. Relying on root-only tricks or on Linux user namespaces can enlarge the kernel attack surface - examples include namespace-rooted capabilities that expose normally privileged APIs - so container-focused primitives should not be treated as general-purpose sandboxing APIs. Emilua experimented with namespaces but now prioritizes mechanisms designed for fine-grained, non-escalating privilege reduction.

Practically, sandboxing operates at the process boundary: isolate components into separate processes, assign each compartment limited credentials, and mediate inter-compartment communication. This aligns with capability-based and actor-model thinking: components own state, spawn others, and exchange addresses and messages without shared memory. For programmers this reduces to a small set of primitives (example Emilua API: spawn_vm(module) -> actor, actor.send(msg), inbox.receive() -> msg) that implement process-based compartments and message passing, enabling controlled, least-privilege execution without expanding kernel trust.