Inscreva-se no feed

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.


Please patch all versions of runc or docker-runc in your environment.  

  1. Don't run random container images from the internet. Only run trusted content.
  2. Always run containers as non root if at all possible (OpenShift Default).
  3. Run your container engines in user namespace if at all possible.
  4. 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.

Sobre o autor

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.

Read full bio

Navegue por canal

automation icon


Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes

AI icon

Inteligência artificial

Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente

open hybrid cloud icon

Nuvem híbrida aberta

Veja como construímos um futuro mais flexível com a nuvem híbrida

security icon


Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias

edge icon

Edge computing

Saiba quais são as atualizações nas plataformas que simplificam as operações na borda

Infrastructure icon


Saiba o que há de mais recente na plataforma Linux empresarial líder mundial

application development icon


Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações

Original series icon

Programas originais

Veja as histórias divertidas de criadores e líderes em tecnologia empresarial