Chapter 10: Security container isolation

Introduction

The chapter introduces container security as protecting the shared host kernel and filesystem, then previews the isolation features Podman uses to do so.

• Shared kernel security risk: Explain why protecting the host kernel and filesystem is the central goal of container security: containers rely on the host kernel, so a compromise can threaten other containers and their data.
  Why it matters: The shared kernel explains why a container escape can affect more than one application.
• Privileged mode security tradeoff: Explain why using --privileged as a first response to denied container access is dangerous: it turns off the container's security separation, whereas understanding the relevant protections can help avoid it.
  Why it matters: A quick fix for an access denial can remove the isolation the host depends on.
• Container isolation feature map: Describe the protections previewed in the introduction: restricted or masked kernel filesystems, capabilities that limit root, and namespaces and SELinux that restrict what container processes can see or access.
  Why it matters: This overview gives the reader a way to connect the chapter's individual mechanisms to host protection.

Key terms: host kernel, host filesystem, container processes, The Container Coloring Book, --privileged, security separation, read-only access, masking, Linux capabilities, PID namespace

10.1 Read-only Linux kernel pseudo filesystems

This section explains how Podman limits a container’s access to kernel pseudo filesystems through read-only mounts, a namespaced /proc, and masked paths.

• Read-only kernel filesystem mounts: Explain why container processes need to read kernel pseudo filesystems but should generally not write to them, especially when running as root. Describe how Podman limits access to /sys and selected filesystems beneath it.
  Why it matters: Read-only mounts let applications obtain needed kernel information without giving container root write access to those filesystems.
• Container-specific proc filesystem: Describe how a PID namespace changes /proc inside a container so it is not the host’s /proc and container processes can affect only other processes in the container.
  Why it matters: A container’s /proc view helps separate its processes from host processes.
• Masked paths against information leaks: Explain why Podman masks selected paths under /sys and the namespaced /proc, and describe the ways it blocks access to files and directories. Note that an application may occasionally need access to a masked directory.
  Why it matters: Masking closes information leaks that can remain even when mounts are read only or /proc is namespaced.

Key terms: kernel pseudo filesystems, /proc, /sys, CAP_SYS_ADMIN, read only, PID namespace, masked paths, /dev/null, read-only tmpfs, bind mounts

10.1.1 Unmasking the masked paths

Shows how to expose masked pseudo-filesystem paths selectively without disabling all container security.

• Selective unmasking of paths: Explain that Podman masks paths such as /proc/scsi by mounting a tmpfs over them, and describe how `--security-opt unmask=/proc/scsi` exposes the underlying files and directories. State that a `*` can unmask all directories under a specified path.
  Why it matters: You can expose a path a container needs without running the whole container in privileged mode.
• Unmasking security tradeoff: Justify targeted unmasking instead of `--privileged`: unmasking makes a container slightly less secure, but privileged mode turns off all the security discussed here.
  Why it matters: The narrower option limits how much protection you give up.

Key terms: --security-opt unmask=/proc/scsi, /proc/scsi, tmpfs, *, --privileged, unmasking

10.1.2 Masking additional paths

This subsection shows how to mask an additional pseudo-filesystem path in a Podman container and raises the question of whether container root can undo such mounts.

• Additional masked paths: Explain when to add a masked path and how to use `--security-opt mask=/proc/sys/dev` to prevent a container process from seeing that path.
  Why it matters: Masking lets you withhold access that an untrusted container does not need.
• Visible mount information: Describe how a container process can see what is mounted over by reading `/proc/self/mountinfo`, and state the unresolved question this raises about container root removing mounts or remounting filesystems read/write.
  Why it matters: Seeing a protective mount is different from being able to undo it.

Key terms: --security-opt mask, masked paths, /proc/sys/dev, /proc/self/mountinfo, remounting filesystems read/write

10.2 Linux capabilities

This section introduces Linux capabilities as a way to divide root privileges, shows how to inspect a process’s capabilities, and explains why containers rarely need the full set.

• Root privileges and capabilities: Explain that Linux capabilities split root’s formerly all-or-nothing power into separate privileges, and that executing a setuid program can give a nonprivileged process privileges.
  Why it matters: This distinction makes it possible to reason about which privileges a process actually needs.
• Current and bounding capability sets: Distinguish the empty current capability set shown for an ordinary user process from its bounding set, which limits the capabilities it can gain by executing a setuid program; describe using capsh to inspect these sets.
  Why it matters: The two sets explain how a process with no current capabilities can still gain privileges through sudo.
• Container capability needs: Explain that most containers do not need the full list of Linux capabilities because they seldom modify the kernel.
  Why it matters: This is the reason the following sections examine limiting container capabilities.

Key terms: root, setuid, Linux capabilities, capsh, current set of capabilities, Bounding set, sudo, containers, kernel

10.2.1 Dropped Linux capabilities

This section shows how Podman limits container root by dropping most Linux capabilities while retaining a small set needed by common applications.

• Default capability restrictions: Explain that Podman gives root inside a container fewer Linux capabilities than root on the host, dropping 30 of 41 by default. Describe how this limits what container processes can do to the operating system.
  Why it matters: Root inside a container does not automatically have the powers of root on the host.
• Purpose of retained capabilities: Describe why Podman retains capabilities such as CAP_SETUID and CAP_SETGID for changing user IDs within a container and CAP_NET_BIND_SERVICE for binding a low-numbered port inside it. Distinguish that internal port permission from a user process's ability to bind port 80 on the host.
  Why it matters: The capabilities Podman retains let applications perform specific tasks without granting container root every host privilege.
• Dropped administration capability: Explain that Podman drops CAP_SYS_ADMIN, preventing container root from unmounting or remounting the read-only filesystems discussed earlier.
  Why it matters: This gives a concrete example of how removing a capability protects an isolation boundary even when a container process runs as root.

Key terms: Linux capabilities, root, capsh, default_capabilities, containers.conf, CAP_SETUID, CAP_SETGID, CAP_NET_BIND_SERVICE, UID, CAP_SYS_ADMIN

10.2.2 Dropped CAP_SYS_ADMIN

This subsection explains why Podman drops the broad CAP_SYS_ADMIN capability by default and why containers may need even fewer capabilities than Podman allows.

• CAP_SYS_ADMIN scope and consequences: Explain why CAP_SYS_ADMIN is especially powerful and what its removal prevents a root process in a Podman container from doing to filesystems.
  Why it matters: Container root cannot override read-only mount points when it lacks the capability needed to remount them.
• Further capability reduction: State that although 11 capabilities remain allowed by default, many containerized processes do not need all of them and can have additional capabilities dropped.
  Why it matters: Default restrictions are a starting point; a process can often run with fewer privileges.

Key terms: CAP_SYS_ADMIN, mount and unmount filesystems, read-only mount points, 11 capabilities, dropping capabilities

10.2.3 Dropping capabilities

This section shows how to reduce a container's privileges by dropping Linux capabilities and notes when a required capability may need to be added back.

• Least-privilege capability dropping: Explain why and how to drop capabilities a containerized application does not need, using --cap-drop=CAP_NET_BIND_SERVICE when it need not bind to ports below 1024 or --cap-drop=all to remove all capabilities.
  Why it matters: Dropping unneeded capabilities limits what a containerized process can do.
• Limits of dropped capabilities: Describe what dropping all capabilities means for a container running as root, and what to do if a container cannot run with its limited capabilities.
  Why it matters: A restricted container may need a specific capability restored to run.

Key terms: least privileges, --cap-drop=CAP_NET_BIND_SERVICE, --cap-drop=all, root, capabilities, modify the kernel

10.2.4 Adding capabilities

This section shows how to give a container one needed Linux capability without disabling its other security protections.

• Selective capability addition: Explain why adding a required capability is preferable to running a container with --privileged, and describe how to grant CAP_NET_RAW for raw IP packets while optionally dropping all other capabilities.
  Why it matters: Granting only the capability an application needs preserves more of the container's security protections.

Key terms: --privileged, --cap-add, --cap-drop, CAP_NET_RAW, raw IP packet

10.2.5 No new privileges

This subsection explains how Podman’s no-new-privileges option prevents container processes from gaining capabilities or changing SELinux labels.

• No-new-privileges security effects: Explain that --security-opt no-new-privileges prevents container processes from gaining privileges beyond those they start with, including through a setuid program, and prevents SELinux label transitions.
  Why it matters: This option limits what a container process can gain after it starts, even if it executes a setuid program.

Key terms: --security-opt no-new-privileges, Linux capabilities, setuid, SELinux label transitions

10.2.6 Root with no capabilities is still dangerous

Dropping Linux capabilities improves container security, but a root process can still pose risks that user namespaces help address.

• Residual risks of container root: Explain why a container process running as root can remain dangerous even after all Linux capabilities are dropped. Describe the risks of modifying root-owned files or being trusted by a client-server application because it is root, and identify user namespaces as Podman's way to address both.
  Why it matters: Removing capabilities does not, by itself, remove the security implications of running as root.

Key terms: Linux capabilities, root, user namespace

10.3 UID isolation: User namespace

This section explains how rootless Podman maps container UIDs to host UIDs, why that avoids host-root processes, and what risk remains when containers share a user namespace.

• Rootless UID mapping: Explain how rootless Podman uses UIDs allocated through /etc/subuid and /etc/subgid so an account can have root access inside a container without being root on the host.
  Why it matters: Container root and host root do not have to be the same identity.
• Shared namespace isolation limits: Explain why the default shared user namespace leaves rootless containers with duplicate UIDs and what a container breakout could access on the host.
  Why it matters: Avoiding host-root processes does not by itself isolate rootless containers from one another or protect the user's files after a breakout.

Key terms: user namespace, UIDs, /etc/subuid, /etc/subgid, rootless Podman, duplicate UIDs, home directory, rootless users

10.3.1 Isolating containers using the - -userns=auto flag

This section shows how Podman’s --userns=auto option assigns separate UID ranges to containers, sizes those ranges, and reuses them after removal.

• Automatic user namespace setup: Describe how to prepare subordinate UID and GID ranges in /etc/subuid and /etc/subgid, then launch a container with --userns=auto so Podman gives it a unique user namespace. Explain why the feature works best when run as root.
  Why it matters: Podman needs an available pool of IDs before it can assign separate ranges to containers.
• UID range sizing and separation: Explain how Podman determines the number of UIDs to allocate from the image’s UIDs and its /etc/passwd file, subject to a default minimum of 1024. Describe how successive nonoverlapping ranges isolate containers, including why a container using UID 2000 receives 2001 UIDs.
  Why it matters: Separate, nonoverlapping ID ranges are the isolation benefit of automatic user namespaces.
• User namespace size overrides: Describe using --userns=auto:size=5000 when the automatic allocation does not provide enough UIDs or GIDs, and state that storage.conf defines the subordinate-ID name and minimum and maximum namespace sizes.
  Why it matters: A container that needs more IDs than Podman allocates automatically can request a larger range.
• Reclaimed UID ranges: Explain that Podman reclaims a container’s allocated UIDs when the container is removed and can assign that range to a later --userns=auto container, as illustrated by successive --rm containers starting at the same UID.
  Why it matters: Reclaiming ranges lets Podman reuse a finite pool without assigning overlapping ranges to active containers.

Key terms: --userns=auto, /etc/subuid, /etc/subgid, UIDs, GIDs, UID range, /etc/passwd, default minimum of 1024, user namespace, --userns=auto:size=5000

10.3.2 User-namespaced Linux capabilities

This section explains why Linux capabilities inside a user namespace give container root limited authority, and demonstrates the limit with network administration and file ownership.

• Namespaced capability boundaries: Explain that a container can appear to have the usual Linux capabilities inside a user namespace, but those capabilities do not grant equivalent authority over host resources. Describe how CAP_NET_ADMIN can change the container’s namespaced network, not the host’s network.
  Why it matters: A capability’s name alone does not tell you how much authority a container has over the host.
• Mapped UID ownership limits: Trace the chown example: container root with CAP_CHOWN cannot change a file’s owner to an unmapped UID, but can use a UID mapped into its user namespace. Explain that --userns=auto gives containers distinct user namespaces, so their root privileges remain limited and do not become host capabilities.
  Why it matters: The ownership test makes the boundary between container root and host authority concrete.

Key terms: Linux capabilities, user namespace, namespaced capabilities, CAP_NET_ADMIN, network namespace, CAP_CHOWN, chown, mapped UID, --userns=auto

10.3.3 Rootless Podman with the - -userns=auto flag

Explains how automatic user namespaces map UIDs in rootless Podman, the limits of the available UID range, and the risk of overlapping mappings.

• Rootless automatic UID mapping: Trace the first rootless --userns=auto container’s UID 0 through the rootless user namespace to the host, and describe how the user’s available UID range limits these containers.
  Why it matters: Following the mapping makes the container limit and its security implications easier to understand.
• Overlapping UID mapping risk: Explain why running a rootless container without --userns=auto can create a UID overlap with automatically isolated containers, and state the suggested way to avoid it.
  Why it matters: Avoiding overlapping UIDs preserves the isolation that the automatic mappings are meant to provide.

Key terms: --userns=auto, rootless user namespace, UID, UIDs, high range of UIDs

10.3.4 User volumes with the - -userns=auto flag

This subsection explains why user namespaces complicate volume ownership and compares Podman’s U and idmap mount options for making a volume accessible.

• User-namespaced volume ownership: Explain why a directory mounted into a container using a user namespace may not be writable: the host directory’s owner UID may not match the UID needed by the container process.
  Why it matters: Volume access depends on how ownership appears inside the container, not just on whether the directory is mounted.
• Volume U ownership option: Describe how the U option on Podman’s --volume flag grants access by chowning source files and directories to match the container’s primary process UID.
  Why it matters: The U option solves the access problem by changing ownership on disk.
• Idmapped volume mounts: Explain how the idmap option remaps source-volume UIDs to the user namespace without chowning files on disk, allowing access through standard permissions and mapping written files back appropriately. State the subsection’s availability caveats: filesystem support is limited, use is privileged at the time described, and crun is the supporting OCI runtime.
  Why it matters: Idmapped mounts address volume access without the on-disk ownership changes made by U.

Key terms: user namespace, UID, volume, --volume, U, chown, source directory, primary process, idmapped mounts, idmap

10.4 Process isolation: PID namespace

This section explains how Podman’s default PID namespace hides host processes from containers and what changes when a container uses the host PID namespace.

• Default PID namespace isolation: Explain that Podman normally gives each container its own PID namespace, so processes inside it see only processes in that container, not other host processes. Describe how hiding information about running applications adds security, even though namespaces were not originally intended as a security mechanism.
  Why it matters: Process visibility can reveal useful information to someone attacking a container.
• Host process visibility option: Describe when an application might need to see host processes, and explain that `--pid=host` turns off PID namespace isolation so the container can see all processes on the system.
  Why it matters: A host-process monitor needs a broader view than the default container process list.
• Host PID security trade-off: Explain that, on an SELinux system, using `--pid=host` also disables SELinux separation because SELinux would block the container’s interactions with host processes. Distinguish that side effect from other protections, such as dropped capabilities and user namespaces, which remain in place and may still block access.
  Why it matters: Seeing host processes does not mean every security restriction has been removed.

Key terms: PID namespace, process isolation, information masking, --pid=host, SELinux separation, dropped capabilities, user namespaces

10.5 Network isolation: Network namespace

This section shows how Podman network namespaces isolate containers on separate networks and how host networking bypasses that isolation.

• Private container network isolation: Explain how to create separate Podman networks, assign a container to one with --network, and verify that a container on the default network or a different private network cannot ping it by name or IP address.
  Why it matters: Separate networks let you control which containers can communicate.
• Host networking tradeoff: Describe how --net=host exposes the host network to a container, allowing it to bind to host ports, and why eliminating the network namespace can sometimes improve performance.
  Why it matters: Host networking changes both the container’s network isolation and how it can use host ports.

Key terms: network namespace, podman network create, --network, net1, net2, --net=host, host network

10.6 IPC isolation: IPC namespace

This section explains how IPC namespaces isolate container communication resources and how Podman can deliberately share those resources between containers or with the host.

• IPC namespace isolation: Explain that an IPC namespace isolates System V IPC objects, POSIX message queues, and /dev/shm from the host and other containers. Describe how this permits containers to reuse IPC names without conflicts and prevents attacks through those resources.
  Why it matters: IPC isolation lets containers use communication resources without exposing them to other containers or the host.
• Container and host IPC sharing: Describe how --ipc=container:NAME or placing containers in a pod makes them share an IPC namespace while remaining isolated from the host. Distinguish that from --ipc=host, which shares the host's IPC namespace.
  Why it matters: Choosing an IPC-sharing mode determines which processes can communicate through IPC resources.
• SELinux labels for shared IPC: Explain that Podman gives containers sharing an IPC namespace the same SELinux label so SELinux does not block their IPC communication. State that --ipc=host disables SELinux separation for that container because otherwise SELinux would block access to host IPC.
  Why it matters: IPC namespace sharing must account for SELinux rules as well as namespace boundaries.

Key terms: IPC namespace, System V IPC objects, POSIX message queues, /dev/shm tmpfs, --ipc=container:NAME, pod, --ipc=host, SELinux label, SELinux separation

10.7 Filesystem isolation: Mount namespace

This section explains how Podman hides the host filesystem with a mount namespace and why SELinux and rootless operation remain important safeguards.

• Mount namespace filesystem isolation: Trace how Podman gives container processes a filesystem view separate from the host: it prepares rootfs, bind mounts volumes onto it, and has the OCI runtime use pivot_root to make rootfs the process’s root mount. Explain that dropping CAP_SYS_ADMIN prevents container processes from changing mounts to expose underlying filesystems.
  Why it matters: This explains both what filesystem a container can see and why its processes cannot normally reveal the host’s mounts.
• Filesystem escape defense in depth: Explain why mount namespaces and dropping CAP_SYS_ADMIN are not sufficient on their own: filesystem escape vulnerabilities can still occur. Describe the section’s runc example and how well-configured SELinux can block it, while rootless Podman also avoids running as root.
  Why it matters: Filesystem isolation needs safeguards against vulnerabilities in the software that starts containers.

Key terms: mount namespace, rootfs, bind mounts, OCI runtime, pivot_root, CAP_SYS_ADMIN, SELinux, rootless Podman, runc, CVE-2019-5736

10.8 Filesystem isolation: SELinux

Introduces SELinux’s label-based filesystem isolation, the two enforcement mechanisms containers use, and where SELinux is available.

• SELinux labels and enforcement: Explain that SELinux labels processes and filesystem objects, and that kernel rules govern how those labels interact. Distinguish type enforcement, which controls processes based on type, from MCS enforcement, which additionally uses assigned categories.
  Why it matters: This gives you the foundation for understanding the two SELinux mechanisms used with containers.
• SELinux distribution availability: State that SELinux is supported on Fedora, RHEL, and other Red Hat distributions, but often not on Debian-based distributions such as Ubuntu.
  Why it matters: Whether your distribution supports SELinux determines whether these mechanisms apply to your system.

Key terms: SELinux, labels, type enforcement, MCS enforcement, categories, Fedora, RHEL, Debian-based distributions, Ubuntu

10.8.1 SELinux type enforcement

This section explains how SELinux type labels let container processes use their own files while blocking access to differently labeled host files, and where type enforcement stops protecting containers.

• SELinux type enforcement rules: Explain how SELinux type enforcement uses labels and explicit allow rules to control access, and identify the types Podman assigns to ordinary container processes and their rootfs files.
  Why it matters: These labels explain why a container can use its own files without gaining access to every file on the host.
• Host file access boundaries: Describe why a container process is denied access to differently labeled host files, including the SSH-directory or temporary-file volume example. Explain how volume relabeling changes that result and why relabeling the SSH directory is discouraged.
  Why it matters: A mounted host path is not automatically safe or accessible; its SELinux label still matters.
• Type enforcement limits and exceptions: Distinguish an ordinary container’s confined container_t type from the unconfined spc_t type used with --privileged, and state that type enforcement protects the host but does not separate one container from another.
  Why it matters: Recognizing both the privileged-container exception and the cross-container limit prevents overstating what type enforcement provides.

Key terms: SELinux label, type, container_t, container_file_t, SELinux policy, ssh_home_t, user_home_t, Permission denied, volume, z

10.8.2 SELinux Multi-Category Security separation

This section explains how Podman uses SELinux MCS labels to separate containers, how volume relabeling controls sharing, and how to disable SELinux container labeling when relabeling is inappropriate.

• MCS container separation: Explain why SELinux type enforcement alone does not separate containers of the same type, and how Podman uses MCS categories on process and filesystem labels to provide that separation.
  Why it matters: MCS labels help prevent one container from accessing another container’s private files.
• MCS category dominance: Describe the section’s qualification to simple label matching: an MCS level can write to a level whose categories it includes, but not one containing a category it lacks.
  Why it matters: This explains why a no-category shared label is accessible without making every differently categorized label accessible.
• Private and shared volume labels: Distinguish the `:Z` and `:z` volume options: `:Z` gives a volume a container-private label, while `:z` relabels it with the shared `s0` level so multiple containers can use it.
  Why it matters: Choosing the right relabeling option determines whether a mounted directory stays private or can be shared.
• Selective SELinux label disabling: Explain why relabeling a home directory with `:Z` or `:z` can cause problems, and describe using `--security-opt label:disable` when a container must mount it without disabling other security mechanisms through `--privileged`.
  Why it matters: This provides an alternative when changing the source directory’s SELinux label is unsafe.

Key terms: Multi-Category Security (MCS), type enforcement, process label, filesystem label, categories, MCS level, dominance, s0, :Z, container private label

10.9 System call isolation seccomp

This section explains how Podman uses seccomp to restrict container system calls, reducing opportunities to exploit the host kernel.

• Seccomp syscall isolation: Explain what a syscall is and how Podman's default seccomp filtering limits the calls container processes can make to the host kernel.
  Why it matters: Blocking an exploitable syscall can prevent a container process from using it to attack the host kernel.
• Seccomp filters and capabilities: Describe where Podman stores its default seccomp filters and how allowed Linux capabilities affect the syscall list, while remaining separately enforced.
  Why it matters: A capability change can affect permitted syscalls, but it does not replace seccomp enforcement.
• Seccomp filter adjustment: Describe how the section demonstrates blocking a syscall and what option is available when the default filter prevents a container from working.
  Why it matters: A blocked syscall can explain a container failure, while disabling the filter removes that protection.

Key terms: syscall, seccomp, Linux kernel, /usr/share/containers/seccomp.json, capabilities, seccomp filters, mkdir, seccomp.json, --security-opt seccomp=unconfined

10.10 Virtual machine isolation

This section explains how running containers in lightweight virtual machines strengthens isolation and what resource-sharing costs come with it.

• Virtual machine isolation mechanism: Explain how OCI runtimes such as Kata and libkrun use KVM to run a container in a lightweight virtual machine with its own kernel and initialization tools, making escape harder by eliminating almost all calls to the host kernel.
  Why it matters: The separate kernel is the key reason VM isolation offers a stronger boundary than default container isolation.
• Virtual machine isolation costs: Describe the tradeoff of VM isolation: containers share fewer services, memory and CPU resources become harder to share, and shared volumes perform worse.
  Why it matters: Stronger isolation is a choice with resource-sharing and performance costs.

Key terms: OCI runtimes, Kata, libkrun, Kernel-based Virtual Machine (KVM), lightweight virtual machine, VM isolation, memory management, CPU, sharing volumes

10.11 Summary

The summary identifies what container security protects and why layering security mechanisms matters.