A flaw in runc (CVE-2019-5736), announced last week, allows container processes to "escape" their containment and execute programs on the host operating system. The good news is that well-configured SELinux can stop it.
Do you enable SELinux (setenforce 1)?
A hypothetical attack using this security hole would start with an attacker packaging a container image with exploit code. If an admin makes the mistake of deploying this container image using tools like podman run
or docker run
or through an orchestrator like Kubernetes, then the executable could overwrite the runc command on the host, giving the attacker full access to the host.
Similar attacks are available when users exec
into a running exploited container image. This exploit effects any container engines (CRI-O, Podman, Docker, Containerd, Buildah) that use the runc container runtime.
Potentially, if an application running in an individual container gets hacked over the network, the attacker could then download the exploit code and break out of the container. Either way, it's bad news. So how can SELinux prevent this?
The vulnerability allows processes within the container to overwrite the /proc/self/exe file, which is meant to point to the currently running executable. For example, the next command shows you /proc/self/exe pointing to "ls", since you used ls to call it:
$ ls -l /proc/self/exe lrwxrwxrwx. 1 dwalsh dwalsh 0 Feb 10 05:45 /proc/self/exe -> /usr/bin/ls
In this exploit, security researchers discovered that it is possible to write to /proc/self/exe when it is pointing to runc, in order to modify that executable. Updated versions of runc now fix this issue.
First, this exploit should not be possible if you run your containers as non-root, which is the Red Hat OpenShift default. This is why almost all containers should be run as non-root.
But for the cases where your containers have to run as root
, you are vulnerable if your system is running setenforce 0
(with SELinux disabled).
SELinux to the rescue
SELinux can block this exploit, as long as you are running in enforcing mode.
Note: The post to the openwall list is incorrect when it states that containers run as container_runtime_t
by default. The tester ran tests on moby-engine, which was not running with the --selinux-enabled flag
. By enabling this flag moby-engine would have been protected also. The container engines packages Podman, Docker, Buildah, and CRI-O should have SELinux enabled by default, and were protected. A bug has been opened with the moby-engine package to change its default to --selinux-enabled
. Docker-ce was vulnerable also since it does not run with --selinux-enabled
by default.
On an SELinux system, container processes are launched as the SELinux type container_t
. SELinux policy defines that the only ordinary files container_t
types can write to are labeled container_file_t
. The default file label of runc is container_runtime_exec_t
, which container_t
would be denied when attempt is made to write to it.
When a attacker tricks a user into running the exploit, SELinux will block the exploit and generate an AVC that looks like:
feb 10 16:08:43 localhost.localdomain audit[1727]: AVC avc: denied { write } for pid=1727 comm="copy" name="runc" dev="sda3" ino=135490239 scontext=system_u:system_r:container_t:s0:c43,c93
tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=0
In the example you'll see SELinux denying the container running as container_t attempting to write over runc which is labeled container_runtime_exec_t.
SELinux blocks the attempted write. Several of the known container exploits that have been found so far are file system exploits (exploits that happen when the process inside of the container gets access to the file system on the host system.) SELinux can be an effective tool to block these types of exploits.
Watch this video on SELinux and Containers from Devconf.CZ 2019.
User Namespace would also protect against this exploit
User namespace could also protect against this exploit, since the process inside of the container while running as root inside of the container, is actually running as non-root outside of the container. Since runc
is owned by root, the process would not be allowed to overwrite it.
Sadly, almost no one runs with user namespace enabled, because of limitations in Linux file systems support for User Namespace. User Namespace features have been added to podman
and the CRI-O
team plans to add features to allow easier running of containers with user namespace separation.
Note: Podman has the capability to run containers in rootless mode, meaning that root inside of the container is actually running as the UID of the user running Podman. In this case the exploit would not be able to work, since runc would be owned by real root on the system.
Conclusion
Please patch all versions of runc or docker-runc in your environment.
- Don't run random container images from the internet. Only run trusted content.
- Always run containers as non root if at all possible (OpenShift Default).
- Run your container engines in user namespace if at all possible.
- Always run with SELinux in enforcing mode and ensure the container engine is running with SELinux separation enabled in production.
Luckily, Red Hat Enterprise Linux, Fedora, and CentOS systems run with SELinux enabled by default. As I often recommend, do not run containers on systems with SELinux disabled or in Permissive mode.
À propos de l'auteur
Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years.
Dan helped developed sVirt, Secure Virtualization as well as the SELinux Sandbox back in RHEL6 an early desktop container tool. Previously, Dan worked Netect/Bindview's on Vulnerability Assessment Products and at Digital Equipment Corporation working on the Athena Project, AltaVista Firewall/Tunnel (VPN) Products. Dan has a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit