Container Security Language

Root-in-container amplifies the blast radius of any application vulnerability.

Running as root inside a container is risky because:
1. If the application is compromised, the attacker has unlimited filesystem and process permissions within the container
2. Some escape vulnerabilities (e.g., runc CVE-2019-5736) are more dangerous when the attacker-controlled process is already root
3. Volume-mounted host paths are accessible with full root permissions
4. In privileged mode or with shared namespaces, container root effectively becomes host root

The fix: add RUN adduser --disabled-password --uid 1000 appuser and USER appuser before the ENTRYPOINT. For port 80/443, use CAP_NET_BIND_SERVICE or a reverse proxy instead of running as root.

Key vocabulary:
• UID 0 — root user; has unrestricted permissions within the container's filesystem and namespace
• USER instruction — Dockerfile instruction that sets the running user for subsequent RUN, CMD, and ENTRYPOINT
• privilege escalation — gaining higher permissions than initially granted (e.g., container root → host root)
• defence-in-depth — layered security so a single failure doesn't lead to full system compromise
• non-root user — a container user with UID > 0 and no elevated kernel privileges

Dropping all capabilities and re-granting only what's needed is the gold standard for container hardening.

Linux capabilities are a fine-grained breakdown of root's privilege set. Docker's default capability set includes many capabilities that most applications don't need:
• CAP_SYS_ADMIN — near-root; can mount filesystems, set resource limits, etc.
• CAP_NET_RAW — can craft raw packets; enables ARP spoofing and network sniffing
• CAP_CHOWN — can change file ownership

Starting from --cap-drop ALL and adding back only NET_BIND_SERVICE (which allows binding to ports < 1024) leaves the container's root user with virtually no dangerous kernel powers — even if the process is running as root.

Key vocabulary:
• Linux capability — a granular subdivision of root's privilege set; e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN
• --cap-drop ALL — Docker flag removing all capabilities from the container's effective set
• --cap-add — Docker flag granting a specific capability back after dropping
• CAP_NET_BIND_SERVICE — capability allowing a process to bind to privileged network ports (< 1024)
• least-privilege — the security principle of granting only the minimum permissions required for a task

Professional vulnerability reporting is specific, actionable, and includes a verification step.

The standard workflow for a CVE finding in a CI scan:
1. Identify — name the CVE ID, affected package, and severity
2. Communicate — concisely describe the finding and remediation plan
3. Remediate — update the vulnerable base image or package
4. Verify — rebuild and rescan to confirm the CVE is gone
5. Document — record the fix in the PR or changelog

Vague escalation (A) or "emergency freeze" (B) adds unnecessary noise. Suppressing a CRITICAL finding (D) without documented risk assessment is a security anti-pattern and can violate compliance requirements.

Key vocabulary:
• CVE — Common Vulnerabilities and Exposures; a standardised identifier for a specific security vulnerability
• CRITICAL — the highest CVE severity; high exploitability or major data-confidentiality impact
• remediation — fixing the vulnerability by updating the affected component
• deployment gate — a CI/CD check that blocks deployment until security or quality criteria are met
• rescan — re-running the image scanner post-remediation to confirm the vulnerabilities are resolved

Seccomp filters system calls at the kernel boundary — a different layer from capabilities.

Seccomp (Secure Computing Mode) works at the boundary between user space and the Linux kernel. Every action an application takes eventually becomes a kernel system call (open, read, write, connect, clone, etc.). A seccomp profile written in BPF (Berkeley Packet Filter) bytecode specifies which syscalls are permitted; all others are blocked with EPERM or cause the process to be killed.

Docker's default seccomp profile blocks ~44 dangerous syscalls (including ptrace, reboot, mount, unshare) while allowing the ~300+ needed for normal operation. A custom, stricter profile reduces the attack surface further for high-risk containers.

Seccomp is complementary to capabilities: capabilities restrict what root can do at a coarse level; seccomp restricts which specific kernel functions any process (root or not) can invoke.

Key vocabulary:
• seccomp — Secure Computing Mode; Linux kernel mechanism for filtering system calls
• syscall (system call) — a request from user-space code to the kernel (e.g., open, write, connect)
• seccomp profile — a JSON/BPF ruleset defining which syscalls are permitted for a container
• attack surface — the set of entry points through which an attacker can attempt exploitation
• BPF — Berkeley Packet Filter; the low-level kernel bytecode used to implement seccomp rules

A read-only root filesystem prevents an attacker from establishing persistence inside the container.

If an attacker achieves remote code execution inside a container with a writable filesystem, they can:
• Modify application binaries or configuration
• Write web shells, reverse shell scripts, or cron jobs
• Persist across container restarts via volume-backed paths

With --read-only, none of these are possible — any write attempt fails. The application's legitimate write needs (temp files, PID files, Unix sockets) are served by tmpfs mounts at specific paths. tmpfs is an in-memory filesystem: writes succeed at runtime but are lost when the container stops — no persistence.

This is a standard CIS Docker Benchmark Level 1 recommendation and is complementary to running as a non-root user.

Key vocabulary:
• --read-only — Docker flag mounting the container root filesystem as read-only
• tmpfs — in-memory filesystem; writes are not persisted to disk and disappear when the container stops
• persistence — an attacker's ability to survive container restarts via filesystem changes
• CIS Docker Benchmark — security configuration guidelines for Docker published by the Center for Internet Security
• attack surface reduction — minimising the number of ways an attacker can exploit or persist in a system