Linux Namespaces: The Foundation of Container Isolation

The Illusion of Isolation

When you run a Docker container, it feels like a lightweight virtual machine - it has its own hostname, its own process tree starting from PID 1, its own network interfaces, and its own filesystem. But there's no hypervisor, no separate kernel. How does Linux create this illusion?

The answer is namespaces - a kernel feature that partitions system resources so that different processes see different views of the system.

The Seven Namespace Types

Linux has seven different namespace types, each isolating a different aspect of the system. Click each type to explore what it isolates and compare host vs namespace views:

How Namespaces Work

The Kernel's Perspective

Every process in Linux has a task_struct containing pointers to its namespace memberships. When a process makes a syscall that depends on isolated resources (like listing PIDs or network interfaces), the kernel consults these pointers to determine what the process should see.

// Simplified view of task_struct namespace membership
struct task_struct {
    // ... other fields ...
    struct nsproxy *nsproxy;  // Points to namespace set
};

struct nsproxy {
    struct uts_namespace *uts_ns;
    struct ipc_namespace *ipc_ns;
    struct mnt_namespace *mnt_ns;
    struct pid_namespace *pid_ns;
    struct net *net_ns;
    struct cgroup_namespace *cgroup_ns;
    struct user_namespace *user_ns;
};

Creating Namespaces

There are three ways for processes to enter namespaces:

# List all namespaces on the system
lsns

# Create new namespace and run command
unshare --pid --fork --mount-proc bash

# Enter existing namespace (requires namespace fd or PID)
nsenter --target 1234 --pid --net bash

# See what namespaces a process belongs to
ls -la /proc/$$/ns/

# Create persistent namespace
ip netns add mynetns
ip netns exec mynetns ip addr

PID Namespace Deep Dive

The PID namespace is perhaps the most iconic - it's what makes container processes appear to start from PID 1. Watch how the same processes have different PIDs depending on which namespace is observing:

Key PID Namespace Properties

1. Hierarchical structure: PID namespaces form a tree. Parent namespaces can see all child namespace PIDs, but not vice versa.

2. PID translation: Each process has a PID in every ancestor namespace up to the root. The kernel maintains this mapping.

3. Init process (PID 1): The first process in a PID namespace becomes init. It has special signal handling - only signals it has handlers for can kill it (except from parent namespace).

4. Orphan adoption: When a parent dies, children are re-parented to the namespace's init process (PID 1), not the host's init.

# Demonstrate PID namespace
$ unshare --pid --fork --mount-proc bash
# Now inside new PID namespace

$ echo $$
1  # We are PID 1!

$ ps aux
USER  PID  COMMAND
root    1  bash
# Only our processes visible

Network Namespace Simulation

Network namespaces provide isolated network stacks. This is how containers get their own IP addresses and port bindings. Build a container-like network topology and watch packets flow:

Container Networking Patterns

Docker and other container runtimes use network namespaces in several configurations:

Mount Namespace: Filesystem Views

The mount namespace was the first namespace type (2002), originally just called "namespace". It isolates the mount table, allowing different processes to see different filesystem hierarchies.

Key Use Cases

1. Container root filesystem: Each container has its own / using pivot_root() or chroot()
2. Bind mounts: Mount host directories into container without affecting host view
3. tmpfs for /tmp: Give each container isolated temporary storage
4. Hiding sensitive paths: Don't mount /etc/shadow into containers

Mount Propagation

Mounts can be configured to propagate (or not) between namespaces:

User Namespace: Unprivileged Containers

The user namespace is the newest (kernel 3.8) and most powerful. It maps UIDs/GIDs between namespaces, enabling rootless containers.

# Run as root inside namespace, nobody outside
$ id
uid=1000(alice) gid=1000(alice)

$ unshare --user --map-root-user bash
$ id
uid=0(root) gid=0(root)

# But on the host, still alice!

Namespace Lifecycle

Creation

Namespaces are created implicitly when the first process enters them (via clone() or unshare()). They're reference-counted kernel objects.

Persistence

A namespace persists as long as:

• At least one process is a member
• A mount holds a reference (/proc/[pid]/ns/[type])
• An open file descriptor refers to it

Destruction

When the last reference is released, the namespace and its resources are cleaned up. For network namespaces, this means all virtual interfaces are destroyed.

# Create persistent network namespace
ip netns add myns
# Creates /var/run/netns/myns bind mount

# Namespace persists even with no processes
ip netns exec myns ip link
# lo only

# Delete when done
ip netns del myns

Security Considerations

Common Escape Vectors

1. Shared kernel: All containers share the host kernel - kernel exploits affect everyone
2. Privileged containers: --privileged disables most isolation
3. Sensitive mounts: Mounting /proc, /sys, or device files can provide escape paths
4. CAP_SYS_ADMIN: This capability enables many namespace-breaking operations

Practical Examples

Manual Container-like Isolation

# Create all namespaces except user (requires root)
unshare --pid --net --mount --uts --ipc --fork bash

# Set hostname (UTS namespace)
hostname my-container

# Mount new proc (after PID namespace)
mount -t proc proc /proc

# Now we have basic container-like isolation!

Inspecting Container Namespaces

# Find container's init process
docker inspect --format '{{.State.Pid}}' mycontainer
# Returns: 12345

# List its namespaces
ls -la /proc/12345/ns/
# lrwxrwxrwx 1 root root 0 ... cgroup -> 'cgroup:[4026532583]'
# lrwxrwxrwx 1 root root 0 ... ipc -> 'ipc:[4026532517]'
# ...

# Enter the container's namespaces manually
nsenter --target 12345 --all bash

Related Concepts

• cgroups: Resource limits for processes (CPU, memory, I/O)
• Containers Under the Hood: How namespaces + cgroups combine to create containers
• Process Management: Understanding fork, exec, and process trees
• Kernel Architecture: How the kernel manages these abstractions