订阅内容

A new CVE, (CVE-2016-9962), for the docker container runtime and runc were recently released. Fixed packages are being prepared and shipped for RHEL as well as Fedora and CentOS. This CVE reports that if you execd into a running container, the processes inside of the container could attack the process that just entered the container.

If this process had open file descriptors, the processes inside of the container could ptrace the new process and gain access to those file descriptors and read/write them, even potentially get access to the host network, or execute commands on the host.

SELinux Reduces Vulnerability

It could do that, if you aren't using SELinux in enforcing mode. If you are, though, SELinux is a great tool for protecting systems from 0 Day vulnerabilities.

Note: SELinux can prevent a process from strace-ing another process if the types or MCS Labels are not the same, but when you exec into a container, docker/runc sets the labels to match the container label.

Mainly this is a host-based attack. This is where SELinux steps in to thwart the attack. SELinux is the only thing that protects the host file system from attacks from inside of the container. If the processes inside of the container get access to a host file and attempt to read and write the content SELinux will check the access.

Example of SELinux protecting the file system.

Let's look at an example. Imagine you exec'd a process which had an open file descriptor for write to a file in the user's homedir into a malicious container. Let's even imagine it is ~/.bashrc. With this vulnerability the container process could write this file. The container processes could write lines that would be executed the next time the admin logged in.

What happens then? You’re PWNED.

Examining this from an SELinux point of view. Container processes run as the container_t type. Files in the users homedir is either labeled user_home_t or admin_home_t (/root).

# ls -Z ~/.bashrc
system_u:object_r:admin_home_t:s0 /root/.bashrc
# ls -Z ~dwalsh/.bashrc
unconfined_u:object_r:user_home_t:s0 /home/dwalsh/.bashrc

Here is a simulation of what would happen if a container process had open file descriptors to the .bashrc files in the admins home directories. Here, runcon changes the SELinux label of the process running echo. The bash script leaks in open file descriptors to .bashrc to the echo command. But SELinux prevents the "hello" from actually being appended to the file.

# runcon system_u:system_r:container_t:s0:c1,c2 echo hello >> ~dwalsh/.bashrc
# runcon system_u:system_r:container_t:s0:c1,c2 echo hello >> ~/.bashrc

Here are the generated SELinux error messages, AVC's, from /var/log/audit/audit.log.

NOTE: These are dontaudited by default, semodule -DB turns off dontaudit rules.

type=AVC msg=audit(1484144451.791:20771): avc:  denied  { `append` } for  pid=22100 comm="echo" path="/root/.bashrc" dev="sda3" ino=1576650 scontext=system_u:system_r:container_t:s0:c1,c2 tcontext=system_u:object_r:admin_home_t:s0 tclass=file permissive=0

type=AVC msg=audit(1484144534.340:21027): avc:  denied  { `append` } for  pid=22479 comm="echo" path="/home/dwalsh/.bashrc" dev="dm-0" ino=262758 scontext=system_u:system_r:container_t:s0:c1,c2 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

SELinux blocked the container process from being able to write to the .bashrc file even if bash opened the descriptor to it and passed it to the container process.

What about network connections?

Now let's look at what would have happened if the process exec'd into the container had an open socket to the internet.

Most likely the user processes that is joining the container would be labeled unconfined_t. The default type for all SELinux users. When you open a tcp_socket, SELinux assigns the label of the process to the label of the socket by default, so the socket would end up being labeled unconfined_t. Now if the container processes attempt to write to the open socket SELinux would check the access. Here I use the sesearch tool to query SELinux policy if this access would be allowed.

# sesearch -A -s container_t -t unconfined_t -c tcp_socket -p write

Are you setenforce 1?

As you can see no allow rules are there so SELinux would deny access. When we heard about this vulnerability we were glad to see that our customers were safer if running containers with setenforce 1. Even with SELinux in enforcement, select information could be leaked, so it is recommended that users patch to fully remediate the issue.

This post has been updated to better reflect SELinux's impact on the Docker exec vulnerability and the changing threat landscape facing Linux containers.


关于作者

Joe Brockmeier is the editorial director of the Red Hat Blog. He also acts as Vice President of Marketing & Publicity for the Apache Software Foundation.

Brockmeier joined Red Hat in 2013 as part of the Open Source and Standards (OSAS) group, now the Open Source Program Office (OSPO). Prior to Red Hat, Brockmeier worked for Citrix on the Apache OpenStack project, and was the first OpenSUSE community manager for Novell between 2008-2010. 

He also has an extensive history in the tech press and publishing, having been editor-in-chief of Linux Magazine, editorial director of Linux.com, and a contributor to LWN.net, ZDNet, UnixReview.com, and many others. 

Read full bio

按频道浏览

automation icon

自动化

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

AI icon

人工智能

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

open hybrid cloud icon

开放混合云

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

security icon

安全防护

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

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

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

application development icon

应用领域

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

Original series icon

原创节目

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