Your container is in security risk by design?

Introduction

Laymen explanation

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.

Security risks as per container 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"

    • Refer this video to know about hacking steps in detail

  • 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

For detailed security practices, please refer here

Reference

https://ericchiang.github.io/post/containers-from-scratch/

https://www.stackrox.com/post/2017/08/hardening-docker-containers-and-hosts-against-vulnerabilities-a-security-toolkit/

https://coreos.com/os/docs/latest/hardening-guide.html

https://sites.google.com/site/jbsakabffoi12449ujkn/home/secure-the-digital-world/risk-with-root-user-in-container

https://www.secjuice.com/how-to-harden-docker-containers/

https://docs.docker.com/engine/security/non-events/

https://www.projectcalico.org