Designing Process Isolation with Linux Network and PID Namespaces

The Problem: Shared System Visibility

In a standard Linux environment, every process shares the same view of the system. Any process with sufficient privileges can see every other process's PID, signal them, or bind to a network port that conflicts with another service. When deploying multiple isolated workloads on a single host, this shared state creates two primary risks: resource contention (e.g., two apps trying to bind to port 80) and information leakage (e.g., a compromised process scanning the process list to find sensitive targets).

The takeaway is that Linux Namespaces allow you to wrap a process in a restricted view of the system, making it believe it has its own private network stack and process tree, without the overhead of a full virtual machine.

Requirements for Isolation

To achieve basic workload isolation, the design must satisfy these three requirements:

• Network Independence: The workload must have its own IP addresses, routing tables, and firewall rules, independent of the host.
• Process Privacy: The workload must not be able to see or interact with processes outside its own boundary.
• Privilege Containment: The workload should be able to perform "root-like" actions (like binding to port 80) inside its namespace without having actual root privileges on the host.

The Smallest Suitable Design

The most efficient implementation uses the unshare() system call or the unshare command-line utility to detach a process from the host's root namespaces. For a basic isolated worker, the design requires three specific namespace types:

1. Network Namespace (net)

This provides a private network stack. When a process is moved to a new network namespace, it loses access to the host's interfaces and only sees a down-state loopback interface (lo) until configured otherwise.

2. PID Namespace (pid)

This isolates the process ID number space. The first process created in a new PID namespace becomes PID 1. This prevents the process from seeing or killing processes in the parent namespace.

3. User Namespace (user)

Crucial for security, the user namespace maps a UID/GID inside the namespace to a different UID/GID on the host. This allows a process to be "root" (UID 0) inside the container while remaining an unprivileged user on the host, preventing privilege escalation if the process escapes the namespace.

Trust and Data Boundaries

The Linux Kernel is the single point of trust. The boundary exists between the isolated namespace and the host (the root namespace). While namespaces isolate visibility, they do not isolate resources. For example, a process in a PID namespace can still consume 100% of the host's CPU. To secure the data boundary, namespaces must be paired with cgroups (control groups) to limit memory and CPU usage.

Implementation Example

To create a minimal isolated environment for testing, run the following command as a standard user on a modern Linux distribution (Kernel 3.8+). This uses the unshare tool to create new network and user namespaces.

# Run as a non-root user
# -n: New network namespace
# -r: Map current user to root in the new namespace
# -p: New PID namespace (requires fork) /bin/sh
unshare -n -r -p /bin/sh

Verification Steps:

1. Check Network: Run ip addr. You should see only the lo interface, and it will likely be DOWN. The host's ethernet or Wi-Fi interfaces will be invisible.
2. Check Processes: Run ps aux. You may still see all host processes because ps reads from /proc, which is still mounted from the host. To fix this, you must mount a private /proc instance:

   mount -t proc proc /proc

   Operational Checks and Failure Modes

   To manage these namespaces in production, use the following diagnostic tools:

   • lsns: Lists all currently active namespaces on the system. Use this to verify that your workloads are actually isolated.
   • nsenter: Allows an administrator to "enter" a namespace by its PID to run diagnostics (e.g., nsenter -t [pid] -n ip addr to check a container's IP).

   Common Failure Modes

   Failure	Cause	Symptom
   Incorrect ps output	Failure to remount /proc	PID namespace is active, but ps still shows host processes.
   PID Exhaustion	Missing cgroup limits	A process creates thousands of threads, hitting the host's pid_max limit.
   Permission Denied	Missing User Namespace	Attempting to use unshare -n without -r or root privileges.

   When to Change the Design

   Namespaces provide logical isolation, not hardware isolation. You should pivot from this design to a Virtual Machine (KVM/QEMU) if any of the following conditions are met:

   • Kernel Version Requirements: The workload requires a different kernel version or specific kernel modules that conflict with the host.
   • Strong Security Guarantees: The workload is untrusted (e.g., running third-party code) and requires a hardware-enforced boundary to prevent kernel-level exploits.
   • Full OS Emulation: The workload requires a non-Linux operating system.