In this lesson, you will learn how to assign unique SELinux contexts to individual container processes to ensure that one compromised container cannot access the memory or files of another.
The Problem with Shared Labels
By default, many container runtimes might label all containers with a generic container_t type. While this provides a basic layer of separation from the host system, it creates a "flat" security model. If two containers are both running as container_t, they share the same security domain, meaning a process in Container A could theoretically interact with resources owned by Container B if the policy allows it.
Applying Unique Contexts
To achieve robust isolation, we move beyond generic labels by applying unique SELinux contexts to specific container processes. When you launch a container with an orchestration tool (like Podman or Docker), you can pass an MCS (Multi-Category Security) label.
The MCS label acts as a dynamic suffix to the base type. For example, instead of both containers being container_t, we assign them distinct category sets:
- Container A:
system_u:system_r:container_t:s0:c101,c102 - Container B:
system_u:system_r:container_t:s0:c205,c206
Even though both use the container_t type, the kernel sees the MCS categories (c101 vs c205) as incompatible. SELinux policy rules require that for a subject to access an object, their MCS levels must dominate each other. Because these categories do not overlap, the kernel will block any attempt by Container A to read or write files labeled for Container B, effectively creating a "sandbox within a sandbox."
Practical Implementation
When starting a container, you can instruct the runtime to generate and apply these unique labels automatically:
# Podman automatically handles MCS separation by default
podman run --security-opt label=type:container_t --name app-one my-image
podman run --security-opt label=type:container_t --name app-two my-image
In the background, the runtime uses the setcon system call to transition the container process into its specific, isolated context. This ensures that even if a container's internal process is hijacked, the Linux kernel enforces strict boundaries preventing it from "escaping" into the memory space of its neighbors.
Key Takeaway: By using unique MCS labels for each container, you leverage SELinux to enforce strict, mandatory isolation boundaries that prevent cross-container interference, even when containers share the same base security type.