Are Docker containers really secure?

No readers like this yet.
Is Occupy Wall St. really an "open source protest?"

Opensource.com

This article is based on a talk I gave at DockerCon this year. It will discuss Docker container security, where we are currently, and where we are headed.

This is part of a series on Docker security, read part two.

Containers do not contain

I hear and read about a lot of people assuming that Docker containers actually sandbox applications—meaning they can run random applications on their system as root with Docker. They believe Docker containers will actually protect their host system.

  • I have heard people say Docker containers are as secure as running processes in separate VMs/KVM.
  • I know people are downloading random Docker images and then launching them on their host.
  • I have even seen PaaS servers (not OpenShift, yet) allowing users to upload their own images to run on a multi-tenant system.
  • I have a co-worker who said: "Docker is about running random code downloaded from the Internet and running it as root."

"Will you walk into my parlour?," said the Spider to the Fly.

Stop assuming that Docker and the Linux kernel protect you from malware.

Do you care?

If you are not running Docker on a multi-tenant system, and you are using good security practices for the services running within a container, you probably do not need to worry. Just assume that privileged processes running within the container are the same as privileged processes running outside of the container.

Some people make the mistake of thinking of containers as a better and faster way of of running virtual machines. From a security point of view, containers are much weaker, which I will cover later in this article.

If you believe as I do, Docker containers should be treated as "container services"—meaning treated as containers running Apache the same way you would treat the Apache service running on your system., this means you would do the following:

  • Drop privileges as quickly as possible
  • Run your services as non-root whenever possible
  • Treat root within a container as if it is root outside of the container

Currently we are telling people in Common Criteria to treat privileged processes within a container with the same criteria as privileged processes running outside the container.

Don't run random Docker images on your system. In a lot of ways I see the Docker container revolution as similar to the Linux revolution around 1999. At that time, when an administrator heard about a new cool Linux service, they would:

  • Search the Internet for a package at places like rpmfind.net or just random websites
  • Download the program onto their system
  • Install if via RPM or make install
  • Run it with privilege

What could go wrong?

Two weeks later the administrator hears about a zlib vulnerability and has to figure out if, while hoping and praying that it's not, their software is vulnerable!

This is where Red Hat distributions and a few other trusted parties have stepped in to save the day. Red Hat Enterprise Linux give administrators:

  • A trusted repository they can download software from
  • Security Updates to fix vulnerabilities
  • A security response team to find and manage vulnerabilities
  • A team of engineers to manage/maintain packages and work on security enhancements
  • Common Criteria Certification to check the security of the operating system

Only run containers from trusted parties. I believe you should continue to get your code/packages from the same people who you have gotten it from in the past. If the code does not come from internal or a trusted third party, do not rely on container technology to protect your host.

So what is the problem? Why don't containers contain?

The biggest problem is everything in Linux is not namespaced. Currently, Docker uses five namespaces to alter processes view of the system: Process, Network, Mount, Hostname, Shared Memory.

While these give the user some level of security it is by no means comprehensive, like KVM. In a KVM environment processes in a virtual machine do not talk to the host kernel directly. They do not have any access to kernel file systems like /sys and /sys/fs, /proc/*.

Device nodes are used to talk to the VMs Kernel not the hosts. Therefore in order to have a privilege escalation out of a VM, the process has to subvirt the VM's kernel, find a vulnerability in the HyperVisor, break through SELinux Controls (sVirt), which are very tight on a VM, and finally attack the hosts kernel.

When you run in a container you have already gotten to the point where you are talking to the host kernel.

Major kernel subsystems are not namespaced like:

  • SELinux
  • Cgroups
  • file systems under /sys
  • /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

Devices are not namespaced:

  • /dev/mem
  • /dev/sd* file system devices
  • Kernel Modules

If you can communicate or attack one of these as a privileged process, you can own the system.

User profile image.
Daniel Walsh has worked in the computer security field for almost 30 years. Dan joined Red Hat in August 2001.

8 Comments

So essentially, if you're running a non-priveleged service in there with no root access, your service should be contained. I don't know why anyone would allow a process in a container to run as root, kind of defies the point, right?

Sadly, the default in Docker is to run everything as root.

You can drop down to a user account by explicitly setting a USER directive in the Dockerfile, or launching with "docker run -u <user>", but you have to know to explicitly do these things. Right now Docker is insecure by default.

In reply to by Chris Done (not verified)

Well not really. You would run a root/priv process within a container for exactly the same reason that you would run one on the host system. To allow it access to system services that are not available to non-privileged processes. The basic idea of this article is to treat these processes the same. In the next article, I will cover what we are doing to make docker mor secure.

Dan,

Can you recommend some materials - books/websites/etc - on Linux security?

Thx,
Jeff

You write:

""""
Devices are not namespaced:

/dev/mem
/dev/sd* file system devices
"""

However, Docker containers do not have access to these devices. Docker has a very short white list for devices. https://github.com/docker/libcontainer/blob/master/devices/defaults.go

The non-root thing is a bit of a red herring, isn't it? It is based on the idea that one would not be able to obtain root inside the container which goes straight back to container hygiene and the complexities of sanitizing imported software.

If containers are only secure if obtaining root is impossible, why even use a container? Just use a non-root user.

rob2: Depends on what you're using a container for.

For example, Docker gives you a namespaced filesystem. So you can bundle up your own dependencies, independent of the host OS. Same goes for networking. This makes it a lot easier to control the environment your app's running in.

Docker is a good distribution platform, but it's not a security platform.

In reply to by rob2 (not verified)

Hi Daniel,

Good article!

Can you please provide more details on libraries and binaries are shared with other containers and the kernel? is this a security concern, can you not share libraries and binaries? is this only enabled via AUFS and Device Mapper?

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.