Latest container exploit (runc) can be blocked by SELinux

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.  

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.