Docker Security: How Containers (Not) Help You

Docker and Security

Things about containers

Security is hot and so is Docker. During the last years Docker has become one of quickest growing container techniques for Linux. While system virtualization continues to grow, the technology allowing flexible containers is growing even faster and starting to compete. In this article we have a look how containers may help you with you security needs and Docker security in particular.

How containers work

Containers are like “chroot” on steroids. Where chroot is faking a new directory structure for processes, a container can do this one multiple levels. This includes the file system, network, IPC (inter process communication), users and also process IDs. Docker, being one of the container solutions, is using two areas from the Linux kernel: namespaces and control groups.

Namespaces

Most of the technology behind containers is achieved by using the Linux namespaces technology. By inserting “walls” between processes, they can’t see each other anymore. Within namespaces we have:

  • IPC (inter-process communication), like sockets
  • Mounts, changing file systems so a process can only see a part (or only read-only access)
  • Network, including network interface, change routes and specific iptables
  • Process IDs, displaying different IDs
  • User mapping, listing different users to each process
  • UTS (for hostname)

Control Groups

Next implemented in Docker is cgroups, abbreviated for control groups. This feature set allows the system to deal with a set of processes regarding their priority and resources. Limiting CPU time, disk IO or maximizing the amount of memory are examples of this. Then there is accounting, which is great for billing your customers or troubleshooting. Last there is the control feature, which allows freezing, restarting and other related command controls for processes.

So how does it help?

All these features sound great and make sense. By restricting (some) resources systems run smoother. With namespaces we can limit connections only to what is required, increasing our security defenses.

There is however a big misconception when it comes to comparing containers and virtual machines. Both technologies look similar on the first glance, but clearly have a big difference: In a virtual machine everything is separated, including the OS, configurations and applications. Containers on the other hand look like a virtual machine when you are inside the container. However, from the host containers just look like normal processes.

Best practices

When working with containers, one should take the same precautions as when dealing with a normal host.

Root

Processes should not be executed under the root context. There is no excuse of doing so. Of course with the normal exception for master process, which then drops privileges. Just use a non-privileged user ID, like www-data.

Images

When using Docker images, don’t leak their unique IDs as they may give others access to your (company) information or intellectual property.

Conclusion

Containers are hot and you should definitely have a look at them to see if they fit your needs. However, they are not a replacement for security. Proper usage of containers will gain you availability, flexibility and when doing it right, a nice increase in security as well. So our advice: use them wisely.

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series and the mission to get Linux and Unix-based systems more secure.

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)


2 comments

  • JavierJavier

    Great post! Just to make it clear, with respect to the root user restriction… If the kernel and Docker were configured to make use of user namespaces… there should be no problem in running applications as root within a container, right? Or even a namespaced root process would pose a threat?

    Reply
    • The thing is, why run something as root at all? Well written software only uses the authorizations needed to run. Most software can drop privileges after certain levels of required access (e.g. opening a socket). Running as root always has increased risks, sometimes beyond what we can think of. So yes, it is a problem :)

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *