New Docker Engine 1.10 brings Enterprise-level security hardening – Secure Computing

Security issues like kernel exploits,  denial-of-service attacks, container breakouts, poisoned images, compromising secrets etc. has been talked a lot in recent times for a container based environnment. With Docker’s “Build, ship and Run” mission, the introduction of the standardized images format has fueled an explosion of interest in container world in the enterprise IT. Docker allows greater sharing of resources and as you have dozens of applications running on your computer system, the chances of exposing your application to the outside world and risk of application vulnerability is sure to increase.

How to use Docker securely?

To use Docker safely, you need to be aware of the potential security issues and the major tools and techniques for securing container-based systems. The new Docker 1.10 release focus on the security aspect of the container technology.This new release brings several security improvements that merits the attention of Docker developers and operations team. In this article, we are going to look at one of the new security feature announced as part of Docker 1.10 release which is rightly  called “secure computing”.

In 2005, one of memory management contributor Andrea Arcangeli, started exploring what we today call “secure computing” (or “seccomp”) feature. Initially, he started working on a feature to enable owners of Linux systems to rent out their CPUs to people doing serious processing work. Allowing strangers to run arbitrary code is something that people tend to be nervous about; they require some pretty strong assurance that this code will not have general access to their systems.Seccomp solves this problem by putting a strict sandbox around processes running code from others. A process running in seccomp mode is severely limited in what it can do; interestingly there are only four system calls – read(), write(), exit(), and sigreturn() – available to it. Attempts to call any other system call result in immediate termination of the process. The idea is that a control process could obtain the code to be run and load it into memory. After setting up its file descriptors appropriately, this process would call:

prctl(PR_SET_SECCOMP, 1);

to enable seccomp mode. This enabled jumping into the guest code, knowing that no real harm could be done. The guest code can run in the CPU and communicate over the file descriptors given to it, but it has no other access to the system.  Later point  of time it was Google Team who thought that seccomp would make a good platform on which to create a “finished implementation” for Linux which they used it for Google Chrome.

Secure computing mode (Seccomp) is purely  a Linux kernel feature which enables you to control which system calls are disabled– and this applies to containers as well, when applied via Docker.You can use it to restrict the actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. You can use this feature to restrict your application’s access.In addition, Docker implemented a default setting which is now part of the Docker daemon.

By default, the new Docker Seccomp profile disables 44 system calls, out of 313 available in 64bit Linux systems. These system calls are listed under Docker official site(shown below for reference).

Source ~ https://docs.docker.com/engine/security/seccomp/

It’s time to look into seccomp feature implementation now. By default, Docker 1.10 available as part of DEB or RPM doesnt support seccomp feature.

Please Note: Seccomp profiles require seccomp 2.2.1 and are only available starting with Debian 9 “Stretch”, Ubuntu 15.10 “Wily”, and Fedora 22. To use this feature on Ubuntu 14.04, Debian Wheezy, or Debian Jessie, you must download the latest static Docker Linux binary.

I am using Ubuntu 14.04.3 for my Docker containers. I will be downloading static Docker Linux binary from https://docs.docker.com/engine/installation/binaries/ and run the binary to get seccomp implementation running.

root@dell:~# wget https://get.docker.com/builds/Linux/x86_64/docker-1.10.2
–2016-02-28 05:33:15–  https://get.docker.com/builds/Linux/x86_64/docker-1.10.2
Connecting to 10.116.2.242:80… connected.
Proxy request sent, awaiting response… 200 OK
Length: 34892323 (33M) [binary/octet-stream]
Saving to: ‘docker-1.10.2.1’

100%[==============================================>] 3,48,92,323  972KB/s   in 31s

2016-02-28 05:33:46 (1.06 MB/s) – ‘docker-1.10.2.1’ saved [34892323/34892323]

root@dell:~# chmod +x docker-1.10.2.1

root@dell:~# ./docker-1.10.2.1 daemon
INFO[0000] [graphdriver] using prior storage driver “aufs”
INFO[0000] Graph migration to content-addressability took 0.00 seconds
INFO[0000] Firewalld running: false
INFO[0000] Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option –bip can be used to set a preferred IP address
..

INFO[0001] Loading containers: done.
INFO[0001] Daemon has completed initialization
INFO[0001] Docker daemon   commit=c3959b1 execdriver=native-0.2 graphdriver=aufs version=1.10.2
INFO[0001] API listen on /var/run/docker.sock

Ensure that Docker service is running fine:

root@dell:~# docker version
Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 21:37:01 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 22:37:33 2016
 OS/Arch:      linux/amd64
root@dell~#

Passing unconfined to run a container without the default seccomp profile

Docker’s default seccomp profile is a whitelist which specifies the calls that are allowed.

Let’s take a simple example:

root@dell:~# docker run –rm -it –security-opt seccomp:unconfined  hello-world

Hello from Docker.
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the “hello-world” image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
https://hub.docker.com

For more examples and ideas, visit:
https://docs.docker.com/userguide/

Passing a profile to run a container with a default seccomp profile

let’s pick up two syscalls – “mount” and “chown” for this example.

Create a json file with the below contents and save it as mypolicy.json.

{

“defaultAction”: “SCMP_ACT_ALLOW”,
    “syscalls”: [
        {
            “name”: “mount”,
            “action”: “SCMP_ACT_ERRNO”
        },
                
        {
            “name”: “chown”,
            “action”: “SCMP_ACT_ERRNO”
        }
        
    ]
}

Ensure that the format is exactly same as json is little delicate in terms of its entries.

Run the below command to enable secomp profile for a container:
root@dell-PowerEdge-R630:~# docker run -it –security-opt seccomp:mypolicy.json busybox sh
/ # ls
bin   dev   etc   home  proc  root  sys   tmp   usr   var
/ # mkdir test
/ # chown root:root test
chown: test: Operation not permitted
/ #

The first command will try to pass seccomp-opt parameter to the container being built. Once the user is inside the container, if he tries to change the ownership of a file he is not permitted to do so. Similarly, he is retricted to run mount command.

In summary, we experienced that the “secured computing” provides the flexibility to harden specific containers based on their actual needs. Said that, it still requires in-depth knowledge of the system calls and container behaviour.This tool arrives as a weapon for Developers and Docker enthusiasts to make Docker’s mission “Build, Ship and Run” more secure and production-ready.