In high-security Linux environments, traditional Discretionary Access Control (DAC)—such as file permissions and capabilities—is insufficient to prevent a compromised container from escaping and compromising the host. Security-Enhanced Linux (SELinux) provides Mandatory Access Control (MAC) to enforce strict isolation. While SELinux Type Enforcement (TE) separates container processes from host processes, it does not separate one container from another. If two containers run under the same SELinux type (e.g., container_t), a breakout from one could potentially interact with the other.
To solve this, container runtimes (like Podman and Docker) utilize Multi-Category Security (MCS). MCS extends SELinux by appending unique, randomized category labels to every container process and its corresponding volumes, ensuring absolute cryptographic-like isolation between containers.
This guide explains how MCS functions architecturally and how administrators can configure, enforce, and troubleshoot MCS labels for container isolation.
Understanding SELinux MCS Labels
A standard SELinux security context consists of four parts: User, Role, Type, and Sensitivity/Category (often referred to as the MLS/MCS level).
For example, a standard container process might have the context:
system_u:system_r:container_t:s0:c123,c456
Here, container_t is the Type Enforcement (TE) label that prevents the container from touching host files (which might be labelled etc_t or var_log_t). The crucial part is the end: s0:c123,c456. This is the MCS label.
When a container engine launches a container, it automatically generates a random pair of categories (e.g., c123,c456) from a pool of 1,024 available categories. It assigns this unique label to both the container process and any volumes mounted into the container. SELinux will mathematically block the container process from reading or writing to any file that does not possess the exact same c123,c456 category pair, effectively sandboxing it from all other container_t processes on the system.
Step 1: Enabling SELinux and Installing Utilities
MCS relies on SELinux being enabled and in Enforcing mode. This is the default on RHEL, Fedora, CentOS, and AlmaLinux.
Verify SELinux status:
sestatus
Ensure the “SELinux mode” is enforcing. If it is permissive, edit /etc/selinux/config, set SELINUX=enforcing, and reboot.
Install the SELinux troubleshooting tools:
sudo dnf install policycoreutils-python-utils setroubleshoot-server
Step 2: Launching Containers with MCS Isolation
Modern container engines like Podman enforce MCS automatically. When you launch a container, Podman automatically selects a random MCS category pair.
Launch a simple container:
podman run -d --name mcs-test alpine sleep 3600
Now, inspect the SELinux context of the running container process using the ps command with the -Z flag (which displays the security context):
ps -eZ | grep mcs-test
# Alternatively, inspect via Podman:
podman top mcs-test huser,label,comm
You will see output similar to system_u:system_r:container_t:s0:c45,c201. The unique c45,c201 pair guarantees isolation.
Step 3: Handling Volume Mounts with the :Z and :z Flags
The most common failure point with MCS isolation occurs when administrators mount host directories into containers. Because the host directory does not possess the randomly generated MCS label of the container, the container process is immediately denied access.
For example, if you run:
podman run -v /opt/data:/data alpine ls /data
This will likely fail with a “Permission denied” error, generating an AVC (Access Vector Cache) denial in the audit logs.
To instruct the container engine to dynamically relabel the host directory with the correct MCS label, you must append the :Z (capital Z) or :z (lowercase z) flag to the volume mount.
- :Z (Private): Applies the specific MCS label of this container (e.g.,
c45,c201) to the host directory. No other container will be able to access this data. - :z (Shared): Applies a generic shared label to the host directory, stripping specific MCS categories. This allows multiple containers to access the same host volume.
To safely mount a private volume:
podman run -d -v /opt/data:/data:Z alpine sleep 3600
If you inspect the host directory’s context with ls -lZ /opt/data, you will see it has been automatically relabelled to match the container’s randomized MCS categories.
Step 4: Troubleshooting MCS Denials
If a container unexpectedly crashes or fails to access data, you must check the SELinux audit logs. The ausearch utility can query the audit daemon for recent SELinux denials (AVCs).
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent
Look for the scontext (source context) and tcontext (target context) fields. If the TE types match (e.g., container_t trying to access container_file_t) but the action is still denied, it is almost certainly an MCS category mismatch. Ensure that your volume mounts are properly using the :Z or :z flags to align the categories.
Conclusion
SELinux Multi-Category Security is the invisible shield that makes multi-tenant container orchestration safe on Linux. By deeply integrating random cryptographic-like categories into every process and file context, administrators can guarantee that even a complete user-space container breakout remains hermetically sealed from neighbouring workloads.