Your container is in security risk by design?

3 min readMar 28, 2020

You know that your container runs as sandbox. Do you think that you will not get affected due to any other malicious container running in the same machine? In reality, it is not true.

Container system is insecure by design!!

Technical explanation

Container technology has radically changed the way that applications are being developed and deployed. Notably, containers dramatically ease dependency management, so shipping new features or code is faster than ever before. While Docker containers and Kubernetes are great for DevOps, they also present new security challenges that both security practitioners and developers must understand and address with diligence.

So what are security risks as per design?

Risks due to shared infra (Host OS)

Each container running on a host shares a common underlying kernel.
If the host OS is compromised, all containers running on it are at risk.

If a container is using a vulnerable library, it could be exploited to gain access to the underlying host.

Risks due to CRI

A CRI(Docker, rkt) acts as lifecycle manager for multiple container.
If a CRI is vulnerable, then a comprised container can take control of host OS

Quote(Refer here) from Palo-Alto about vulnerability in docker cp command : “If a user executes the vulnerable cp command to copy files out of the compromised container, the attacker can escape and take full root control of the host and all other containers in it”

This Docker vulnerability was tracked as CVE-2019–14271 and the security issue fixed with Docker version 19.03.1

Risks due to Docker design

Docker engine needs root permission

Any vulnerability in docker engine can result in uninterrupted access to full underlying OS (file system, user base, memory, CPU and so on…..)

Docker containers, by default, runs with root permission

A container with root user can access host machine data which is not accessible in host by non-root. Refer here for detail about example hacking

So, what is the solution?

Basic safety as per Linux design

Using namespace and CGroup

Containers uses Linux control groups (cgroups) and namespaces. Tools like Docker and rkt are just wrappers around things built into every modern kernel.
cgroups, short for control groups, allow kernel imposed restriction on resources like memory and CPU.
Namespace provides isolation among various containers. For example, two containers can’t see traffic of each other. Two containers can’t see processes running on each other

Securing the host OS

It is achieved via combined effort of

Host OS security strengthening
Container security strengthening

Linux Security modules for OS strengthening

Linux provides several out-of-the-box security modules.
Some of the popular ones are
SELinux,
AppArmor and
seccomp

Linux capabilities

Linux capabilities are groups of permissions that can be given to child processes.
Child processes cannot acquire newer capabilities.The idea behind capabilities is that no process should have all privileges, but instead, have only enough privileges to perform their intended service.
This Linux feature should be used for ensuring least privilege security best practice. In other words, a container should be provided only enough privileges to perform their intended service.
Some capabilities give excessive privileges. For example, SYS_ADMIN, SETUID

Container Runtime Security Practices

Basic safety nets

Update CRI (Docker, rkt) — Referring above mentioned docker CVE, it is important to keep docker version updated
Deploy Only Trusted Docker Images
A malicious container can be loaded if an attacker has replaced the original image with the malicious one
So, it is important to allow containers from trusted sources only
Start With A Clean OS build
It helps to ensure that host machine is secure from boot
Scan the Image For Known Vulnerabilities