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 exec
d 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.
About the author
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.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit