Iscriviti al feed

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.


Sull'autore

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

Ricerca per canale

automation icon

Automazione

Novità sull'automazione IT di tecnologie, team e ambienti

AI icon

Intelligenza artificiale

Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque

open hybrid cloud icon

Hybrid cloud open source

Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido

security icon

Sicurezza

Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti

edge icon

Edge computing

Aggiornamenti sulle piattaforme che semplificano l'operatività edge

Infrastructure icon

Infrastruttura

Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale

application development icon

Applicazioni

Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili

Original series icon

Serie originali

Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende