Preface: A Pod represents a single instance of a running process in your cluster. Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources.
Background: Containerd was designed to be used by Docker and Kubernetes as well as any other container platform that wants to abstract away syscalls or OS specific functionality to run containers on linux, windows, solaris, or other operation system. Kubernetes is removing support for Docker as a container runtime. Kubernetes does not actually handle the process of running containers on a machine. Instead, it relies on another piece of software called a container runtime. CRI is a containerd plugin implementation of Kubernetes container runtime interface (CRI). With it, you could run Kubernetes using containerd as the container runtime.
Vulnerability details: On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access privileged host files.
Additional: Simple conceptual diagram attached.
Remediation: This issue has been resolved in version 1.5.9. Users are advised to upgrade as soon as possible.