Security-Enhanced Linux (SELinux) is a brave attempt to clean up the security holes in Linux containers and is an implementation of a Mandatory Access Control (MAC) mechanism, Multi-Level Security (MLS), and Multi-Category Security (MCS) in the Linux kernel. There is a new collaborative initiative, referred to as the sVirt project, which is being built on SELinux, and this is getting integrated with Libvirt to provide an adaptable MAC framework for VMs as well as containers. This new architecture provides a sheltered separation and safety net for containers, as it primarily prevents root processes, within the container, from interfacing and interfering with other processes running outside this container. Docker containers are automatically assigned to an SELinux context specified in the SELinux policy.

SELinux always checks for all the allowed operations after the standard Discretionary Access Control (DAC) is completely checked. SELinux can establish and enforce rules on files and processes in a Linux system and on their actions based on defined policies. As per the SELinux specifications, files, including directories and devices, are referred to as objects. Similarly, processes, such as a user running a command, are being termed as subjects. Most operating systems use a DAC system that controls how subjects interact with objects and one another. Using DAC on operating systems, users can control the permissions of their own objects. For example, on a Linux OS, users can make their home directories readable, giving users and subjects a handle to steal potentially sensitive information. However, DAC alone is not a fool-proof security method and DAC access decisions are solely based on user identity and ownership. Generally, DAC simply ignores other security enabling parameters, such as the role of the user, the function, trustworthiness of the program, and the sensitivity and integrity of the data.

As each user typically has the complete discretion over their files, ensuring a system-wide security policy is difficult. Further, every program run by a user simply inherits all the permissions granted to the user, and the user is free to change the access to their files. All this leads to a minimal protection against malicious software. Many system services and privileged programs run with coarse-grained privileges so that any flaw in any one of these programs can be easily exploited and extended to gain the catastrophic access to the system.

As mentioned at the beginning, SELinux adds MAC to the Linux kernel. This means that the owners of an object have no control or discretion over the access to an object. The kernel enforces MAC, which is a general-purpose MAC mechanism, and it needs the ability to enforce administratively set security policies to all the processes and files in the system. These files and processes will be used to base decisions on labels containing a variety of security-centric information.

MAC has the inherent capability to sufficiently protect the system. Further on, MAC ensures application security against any willful hacking and tampering. MAC also provides a strong separation of applications so that any attacked and compromised application runs separately.

Next in line is MCS. It is mainly used to protect containers from other containers. That is, any affected container does not have the capability to bring down other containers in the same Docker host. MCS is based on the MLS capability and uniquely takes advantage of the last component of the SELinux label, the MLS field. In general, when containers are launched, the Docker daemon picks a random MCS label. The Docker daemon labels all of the content in the container with that MCS label. When the daemon launches the container process, it tells the kernel to label the processes with the same MCS label. The kernel only allows the container processes to read/write their own content as long as their MCS label matches the filesystem content's MCS label. The kernel blocks the container processes from reading/writing content that is labeled with a different MCS label. This way, a hacked container process is prevented from attacking different containers. The Docker daemon is responsible for guaranteeing that no containers use the same MCS label. The cascading of errors among containers is prohibited through the adroit usage of MCS.

SELinux is not installed by default in Ubuntu 16.04, unlike, Red Hat Fedora or CentOS distribution, so install SELinux by running the apt-get command, as shown here:

$ sudo apt-get install selinux

Then continue to enable the SELinux mode by running the following sed scripts:

$ sudo sed -i 's/SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
$ sudo sed -i 's/SELINUXTYPE=.*/SELINUXTYPE=default/' 
/etc/selinux/config  

Application Armor (AppArmor) is an effective and easy-to-use Linux application security system. AppArmor proactively protects the OS and applications from any kind of external or internal threats and prevents even unknown application flaws from being misused by any hackers. AppArmor is being made available for guaranteeing Docker containers and applications present inside the containers. Policies are turning out to be a powerful mechanism for ensuring container security. Policy formulation and the automated enforcement of policies go a long way in guaranteeing the safety of containers. AppArmor comes by default with Ubuntu 16.04, so this is always recommended to be used.

On Docker versions 1.13.0 and later, the Docker binary generates this profile in TMPFS and then loads it into the kernel. On Docker versions earlier than 1.13.0, this profile is generated in /etc/apparmor.d/docker instead.

The docker-default profile is the default one for running containers. It is moderately protective while providing wide application compatibility. When you run a container, it uses the docker-default policy unless you override it with the security-opt option. For example, the following explicitly specifies the default policy:

$ docker run --rm -it --security-opt 
         apparmor=docker-default hello-world

Secure computing mode (seccomp) is supported by the Docker Engine, a security feature made available in the Linux kernel. This allows the administrator to restrict the actions available within a container down to the granularity of a single system call. This capability greatly restricts the access that an application container has to the host system to perform actions. Enterprises can configure seccomp profiles accordingly and apply them to the Docker environment.

The default seccomp profile provides a sane default for running containers with seccomp and disables around 44 system calls out of over 300. It is moderately protective while providing wide application compatibility.

The vast majority of applications will be able to operate without any issue with the default profile. In fact, the default profile has been able to proactively protect Dockerized applications from several previously unknown bugs.

This is enabled by default on Ubuntu 16.04:

$ cat /boot/config-`uname -r` | grep CONFIG_SECCOMP= CONFIG_SECCOMP=y

SCONE: Secure Linux Containers with Intel SGX, is described by Sergei Arnautov and his team as a secure container mechanism for Docker that uses the SGX trusted execution support of Intel CPUs to protect container processes from outside attacks. The design objectives of SCONE are fixed as follows:

• Firstly, it attains small Trusted Computing Base (TCB)
• Secondly, it has to have a low-performance overhead

SCONE offers a secure C standard library interface that transparently encrypts/decrypts I/O data to significantly reduce the performance impact of thread synchronization and system calls within SGX enclaves. SCONE supports user-level threading and asynchronous system calls. As per their research paper, the evaluation of SCONE is greatly appreciated by Docker fans.