Waybill runs as root in its container SEC-102

Namespaces, cgroups, and capabilities make a process a container. Root inside it is still a risk.

A container is a process with restrictions

Start with the claim Container Security makes early: a container is an ordinary Linux process, started with a set of restrictions. Run ps on the host and you will see it. What makes it "contained" is three kernel mechanisms applied together.

Namespaces: what the process can see

Each namespace gives the process a private copy of one kind of system resource:

The network namespace matters most day to day. A container has its own localhost. The “Container networking and composition” notes build on that.

cgroups: what the process can use

Control groups account for and limit resources: memory, CPU shares and quotas, I/O, and the number of processes. A container's --memory=512m is a cgroup limit. When the processes inside exceed it, the kernel's OOM killer acts within that cgroup, whatever the host has free. That is the same mechanism described in the “Memory, limits, and a method for performance” notes, now per container. The pids limit also stops fork bombs inside one container from exhausting the host.

Capabilities: root in pieces

Traditional Unix has one powerful user. Linux splits root's power into capabilities: binding ports below 1024 (CAP_NET_BIND_SERVICE), changing file ownership (CAP_CHOWN), and the catch-all CAP_SYS_ADMIN. Docker starts containers with a reduced default set and applies a seccomp profile that blocks dangerous system calls. That reduces risk but does not remove it.

Why root in a container still matters

Without user-namespace remapping, UID 0 in the container is UID 0 on the host, restricted by the mechanisms above. Any of these turns a container compromise into a host compromise: a kernel or runtime escape bug, a mounted Docker socket, a sensitive host path mounted in, or --privileged. The defence is layered least privilege:

1. Run as a non-root user. Add USER 10001 (or a named user) in the image, and give that user only the files it needs.
2. Drop capabilities. --cap-drop=ALL, then add back only what is proven necessary.
3. Read-only root filesystem. --read-only, with explicit volumes or tmpfs for writable paths.
4. No --privileged, no Docker socket mounts, and no host paths beyond what is needed.
5. Rootless mode or user namespaces where the platform supports them.

A web service listening on 8080 and reading its config needs none of root's powers. That is the situation in the lab.

Verify, do not assume

docker exec waybill id                       # uid=10001 ...
docker inspect waybill --format '{{.Config.User}} {{.HostConfig.CapDrop}} {{.HostConfig.ReadonlyRootfs}}'
grep Cap /proc/$(docker inspect -f '{{.State.Pid}}' waybill)/status   # effective capability bitmaps

Confirm the service still works after each restriction. The lab's validator checks both that privilege dropped and that health is unchanged.

Key terms

Namespace

A kernel feature that gives a process its own view of one resource type, such as PIDs, mounts, network, hostname (UTS), IPC, users, or cgroups.

Capability

One slice of root's privileges, such as CAP_NET_BIND_SERVICE or CAP_SYS_ADMIN, that can be granted or dropped independently.

Rootless container

A container whose root user maps to an unprivileged user on the host through a user namespace.

Read-only root filesystem

Running with the image layers mounted read-only, so the process can write only to declared volumes or tmpfs.

Read further

• Container Security, Chapters "Linux System Calls, Permissions, and Capabilities", "Control Groups", and "Container Isolation" (Purchase)
  Build a container by hand with unshare and chroot as the book does. Note which namespace provides which isolation, and how capabilities split root's power into pieces.
• Container Security, Chapter "Strengthening Container Isolation" (Purchase)
  seccomp, AppArmor and SELinux, and the discussion of user namespaces and rootless containers. Note which defaults Docker applies for you.

Classify access by risk, grant narrow and auditable permissions, and make denials easy to diagnose.

Access is a design decision

Building Secure and Reliable Systems argues that least privilege has to be designed in. Retrofitting it to a system where everyone has root rarely works. The chapter's first step is to classify access by risk. Reading public metrics is low risk. Deploying a service, reading customer data, or changing access control is high risk. Each class gets proportionate controls:

The same thinking applies to machine identities. A deploy bot, a CI runner, and a monitoring agent each get a role scoped to what they do. Shared "admin" identities do not survive this classification.

Small interfaces beat big hammers

The book prefers small functional APIs over general access. If on-call engineers need to restart Waybill, give them a tool or API that restarts Waybill, not an interactive root shell on every host. A narrow interface:

• exposes only intended actions,
• can be audited meaningfully, since the logs say "restart waybill by sal" and not a list of shell keystrokes,
• can enforce policy (rate limits, approvals) in one place,
• and limits damage from mistakes and compromised accounts.

Kubernetes RBAC, sudo rules for specific commands, and deployment pipelines that hold the only production credentials all apply the idea.

Advanced controls

For high-risk actions the book describes several controls:

• Multi-party authorisation: a second person approves the action. It stops both insiders and single compromised accounts.
• Temporary access: grants that expire automatically, requested with a business justification.
• Proxies: privileged actions go through an audited proxy instead of direct credentials.
• Break-glass: an emergency bypass that is always available, always logged, alerts security when used, and is reviewed afterwards. It must exist, because outages happen when normal paths are broken. It must be loud, so it does not become the normal path.

Make denials diagnosable

Least privilege fails socially when denials are mysterious. Engineers then lobby for broad roles "to be safe". The book recommends making denial messages say who was denied what on which resource and how to request access. Kubernetes does this well ("User system:serviceaccount:ci:deploy-bot cannot patch resource deployments in API group apps in the namespace waybill"). That message is a complete specification of the missing permission.

The operator's discipline is to read the denial, grant exactly that, and record why. The tempting alternative, binding cluster-admin or running chmod 777 "temporarily", turns the next incident into a security incident.

Least privilege also protects against mistakes

Most damage from excessive access is not malicious. A script run against the wrong environment, a command typed on the wrong host, or an automation bug with admin credentials can all destroy as thoroughly as an attacker. BSRS stresses this overlap between security and reliability. Narrow, scoped access shrinks the blast radius of every kind of error.

Key terms

Least privilege

Every identity, human or machine, has only the access its current task requires, for only as long as needed.

Break-glass

An emergency path that bypasses normal controls. It is tightly audited and triggers alerts and review whenever used.

Multi-party authorisation

A sensitive action requires approval from a second person before it runs.

Blast radius

How much can be damaged if one identity or component is compromised or misused.

Read further

• Building Secure and Reliable Systems, Ch. 5, "Design for Least Privilege" (Free to read online)
  Classifying access by risk, small functional APIs, breakglass mechanisms, auditing, and the advanced controls (multi-party authorisation, temporary access, proxies). Also read the section on diagnosing access denials.
• Building Secure and Reliable Systems, Ch. 2, "Understanding Adversaries" (Free to read online)
  Attacker motivations and profiles, including insiders. Note why least privilege also limits honest mistakes.
• Container Security, Chapter "Container Security Threats" (Purchase)
  The threat model for containerised systems and the security principles at the end, especially least privilege and defence in depth.