Original translation from: Http://opensource.com/business/14/7/docker-security-selinux
This article is based on a lecture I have had this year in Dockercon, which will discuss the security issues we hear about Docker containers today.
Containers are not "inclusive"
I hear also read many assumptions that Docker containers are the view of application sandbox-which means they can use Docker with root privileges on their systems to run arbitrary programs. They believe that the Docker containers will protect their host systems.
- I heard people say that Docker containers are as safe as VMS/KVM execution programs.
- I know people are randomly downloading docker images and executing them on their hosts.
- I even see PAAs servers (not openshift) that allow users to upload their own images running on a multi-tenant system
- I have a colleague who says: Docker is downloading arbitrary code from the Internet and running in root mode
"Would you like to come to my living room," the spider said to the butterfly. Stop this idea of setting up Docker and Linux to protect you from malicious software!
Do you care? If you are not running Docker in a multi-tenant system, and you use a good security policy for the services running in the container, Then you don't have to worry about it. Just assume that the privileged process running in the container is like a privileged process outside the container. Some people mistakenly think that containers are a better and faster way than virtual machines, but from a security standpoint, containers are more vulnerable, which I'll explain later in the article. If you believe what I say, Docker containers should be treated as "container services"-which means that you want to run Apache as an Apache service running on your host system, that is to say:
- Reduce privileges as soon as possible
- Run your service in a non-root mode whenever possible
- Consider the root mode in the container as the root mode outside the container
Currently we are in the general specification of a privileged process that tells people to put the privileged process of a container outside the container.
Instead of running arbitrary docker images in your system, I see in many ways that the Docker container revolution is similar to the 1999 Linux Revolution, when an administrator hears a new cool Linux service, they will:
- Go to rpmfind.net and some other websites to search for packages
- Download these packages
- Install via RPM or make install
- Execute in Manager mode
What is the problem?
Two weeks later the administrator hears a zlib vulnerability and has to point out (they hope and pray not) that the software is unsafe!
This is the time for Red Hat distributions and other trusted third parties to intervene and save them, and Red Hat's enterprise Linux provides administrators with:
- A secure repository that provides downloads
- Secure upgrade to fix the problem
- The team that found the problem and repaired it
- Management/maintenance/Safety Enhancement Team of Engineers
- Common authentication standards to check OS security issues
Just run containers from trusted organizations, and I'm sure you should continue to get the code/package from the same people, just like you did before. If the code doesn't come from there, don't trust that the container technology will protect your console.
So what's the problem? Why are containers not "inclusive"?
The biggest problem is that everything in Linux is not namespace (namespaced). Docker now uses 5 namespaces to change the process of the system: process, network, MOUNT, hostname, shared memory. Although there is a certain level of security for users, it is not possible to implement full security protections like KVM. In a KVM environment, processes do not interact directly with the host's kernel. They also do not access the kernel's file systems such as/sys and/sys/fs,/proc/*
Device nodes are used to interact with the VMS kernel, not the host. Therefore, to extend the privilege level across VMS, the process is going to attack the VM kernel, find Hypervisor's weaknesses, break the SELinux control (Svirt), and eventually attack the host's kernel.
When you run in a container, you are directly able to deal with the core of the host.
The primary kernel subsystem that is not considered a namespace is as follows:
- SELinux
- Cgroups
- File system under/sys
- /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
Devices that are not treated as namespaces:
- /dev/mem
- /dev/sd* File System devices
- Kernel modules
If you are communicating or attacking one of these modules through a privileged process, you have the entire system.
