MID-015: Containerization
Mitigation Tier: Intermediate
Description
Some operating systems offer the ability to create containers that wrap small sets of applications in isolated partitions. Each container has its own view of system resources that is isolated from other containers and the host OS. Examples include Linux containers (LXC), Docker, BSD jails, etc. Container partitions are created by the host OS kernel which provides each container with isolated copies of various system resources, such as a unique guest filesystem, partitioned network stack, process ID space, user ID space, etc. Unlike virtualization (see MID-022), container systems do not need to provide virtualized views of hardware running separate full operating systems, instead abstracting at the level of a single kernel instance allows for lower performance overhead. However, OS kernels typically have a larger attack surface than a VM system’s hypervisor, so containers are generally considered to be a weaker form of isolation than virtualization [2]. Device designers should consider risk vs performance tradeoffs when selecting which isolation technology to implement, although both technologies can used in parallel to achieve the desired balance.
Containers offer several opportunities for security hardening. All the capabilities of MID-012 and MID-013 are available within each container partition. Furthermore, container filesystems can be stripped down to the bare minimum necessary for the applications within the container to function (see MID-016 – Least Functionality). So-called “rootless” container design patterns can be employed such that all processes within a container context run with unprivileged non-root user permissions. Host-side orchestration tools like Docker, can enforce additional security restrictions over container contexts when they are created [1]. For example, seccomp syscall filters can be applied to each container to restrict what kernel interfaces any process within that container may access, which reduces the opportunities for container breakout attacks [4]. Finally, device developers may consider utilizing non-persistent or immutable (read-only) container image design patterns. These increase the difficulty for attackers to establish a foothold within a container while simplifying the process of restoring containers to a known-good state through restarting containers from an integrity-checked known-good state periodically or in response to indicators of compromise.
Note: Containers can offer additional non-security benefits to device developers. The additional modularization they provide can make application development and maintenance more efficient, including making various devops practices more accessible to embedded device development workflows [6].
IEC 62443 4-2 Mappings
SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
CR 3.4 – Software and information integrity
References
[1] Docker. “Docker security.” docker.com. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.docker.com/engine/security/
[2] M. Ahuje. “CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit.” crowdstrike.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/
[4] V. Rothberg. “Improving Linux container security with seccomp.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/sysadmin/container-security-seccomp
[5] M. Kerrisk. “seccomp.” man7.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.man7.org/linux/man-pages/man2/seccomp.2.html
[6] Wind River Systems Inc. “What are Embedded Containers?” Accessed: Sep. 5, 2024. [Online.] Available: https://www.windriver.com/solutions/learning/embedded-containers