订阅内容

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.


关于作者

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
UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事