CONCEPT Cited by 1 source
Linux namespaces¶
Linux namespaces are the kernel primitive that isolates what a process can see of the system — a process in a namespace sees its own view of a resource type (processes, mount points, network interfaces, users, etc.) distinct from the host's view. Namespaces are the foundation every Linux container runtime is built on; they are independent of any container platform.
Seven namespace types, each scoped to one resource:
| Namespace | Isolates |
|---|---|
| user | UID / GID mappings (a process can be "root" inside but unprivileged outside) |
| pid | Process ID table (PID 1 inside is the container's init) |
| mount (mnt) | Filesystem mount tree |
| network (net) | Network interfaces, routing tables, iptables, sockets |
| IPC | System V / POSIX IPC objects |
| UTS | Hostname + domainname |
| cgroup | cgroup-hierarchy view |
(Cgroups handle how much of each resource a process can use; namespaces handle which view of it the process sees. Different axis.)
Role in sandboxing¶
Namespaces are the containment half of a
server-side sandbox. A
process in a fresh mnt + pid + net + user namespace:
- Cannot see host files except what was explicitly mounted.
- Cannot see host processes.
- Cannot open a socket to the host network.
- Has no host-privileged identity.
Figma's RenderServer nsjail config uses exactly this stack: "nsjail starts a new RenderServer process in a new user, pid, mount, and network namespace with no network access." (Source: sources/2026-04-21-figma-server-side-sandboxing-containers-and-seccomp)
Combined with seccomp (what kernel code can the process reach) they form the two-axis isolation that containers + layered sandboxes depend on.
Where the attack surface is¶
Namespaces are kernel code, so bugs in namespace implementation are container-escape vectors. High- profile historical cases include user-namespace privilege escalation bugs (CVE-2018-18955) and various mount-namespace exploits. Unlike seccomp filters (which the workload author writes), namespace isolation relies on kernel correctness the workload author cannot audit.
Namespaces alone are not enough¶
Figma's framing emphasises that namespaces are necessary but not sufficient:
"As with VMs, placing a potentially compromised workload in a container is not necessarily sufficient for security. You need to strengthen the container configuration to prevent host takeover, and the overall container infrastructure architecture should limit the impact of a compromised container."
So real-world sandboxes compose namespaces with:
- cgroups for resource limits.
- seccomp for syscall filtering.
- Capability dropping for Linux capability sets.
- LSM (SELinux / AppArmor) for mandatory access control.
The best-of-breed example of this composition is systems/nsjail (and systems/firejail).
Seen in¶
- sources/2026-04-21-figma-server-side-sandboxing-containers-and-seccomp — explicit enumeration of the four namespace types used in Figma's nsjail config for RenderServer (user + pid + mount
- network), and framing of namespaces as one of three attack-surface axes for container escape.