Wednesday, August 12, 2015

Dissecting Docker security - Part 1

What is Docker?


Docker is an open source project that automates deploying of software applications inside a Linux container. Linux containers utilize namespaces and cgroups, for providing fast and reliable isolation to the software applications.  A high end system can be effectively utilized run thousands of containers, belonging to varied clients or tenants. Such systems have to be secured as an exploited application executed with high privilege rights or permissions, can bring bring the system down.

Why Security is important for Docker?


The isolation provided by Linux containers, are very secure and cover most of the aspects of security. The containers are widely used,  but do not find its way when talked about multi-tenant environments. The reasons for not having such environments using containers is well called for due to missing constructs, which have to be investigated and or constructed.

Security Constructs


There have been a number of feature additions to Linux container security features, which, while
evaluating vulnerability focuses on three major areas. Even though these security constructs suffice but lack in a number of aspects, thus non giving out a complete solution.

1. The Linux kernel security features


a) Namespace

Linux namespaces is a lightweight process virtualization. It enables a process to have different views of the system. The processes running within containers cannot see the system or other containers. Linux kernel provides six different types of namespaces - mount, process, network stack, inter process communication, hostname and user. Each container gets its own network stack; containers do not get privileged access to containers sockets or interfaces of other containers. Mount namespaces ensures volume mounts in one containers are not see of accessed to other containers processes, though it may be seen at the host.

b) Control groups (cgroups)

Cgroups is a mechanism in a kernel for grouping, tracking and limiting kernel resource usage to a process. Cgroups ensure each process gets its own fair share of resources, and a single container cannot bring down system by over-exhausting resources.

2. Linux kernel capabilities


The Linux style capabilities come in two varieties, regular user and root. The users have to impersonate as root, to get capabilities of the root user. However, having such large access of user capabilities is more risky than advantageous. Therefore, having only two types of privileges is not sufficient; a more granular privilege set is required. The POSIX capabilities are exactly designed for this purpose.

3. The Linux kernel hardening features


a. Linux Security Modules - SELinux , AppArmor


i. Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies for Linux kernel. It is included with CentOS / RHEL / Fedora Linux, Debian / Ubuntu, Suse, Slackware and many other distributions.


ii. AppArmor is the most effective and easy-to-use Linux application security system available on the market today. AppArmor is a security framework that proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good program behavior and preventing even unknown software flaws from being exploited.


iii. Grsecurity is a set of patches for the Linux kernel with an emphasis on enhancing security. It utilizes a multi-layered detection, prevention and powerful policy setup.It can be easily argued that aesthetics of Linux security modules makes them a unfavorable option for implementing security policies.


b. SECCOMP


Secure computing mode is a facility, which provides Linux kernel sandboxing by restricting access to the certain system calls, which a program can make. This feature thus does not let an exploiting program take control of the system, even when executed with super privileged user.

Evaluating Security Constructs


It can be said that above mentioned security constructs suffice most of the use-cases, but

a) Are the skills needed for using these require more than what application developer would know?  

b) Are these constructs easily maintainable? Can they withstand change - migration of application etc.

c) Do using of these require change in application code or program?

d) Are these tools agnostic of the platform they run on? For e.g. a SELinux policy does it work with centos as base os and ubuntu as container os?

My earlier blog I have measured aesthetics of Linux security modules, as I do find them use-full but not very usable.

Conclusion


Before choosing a particular security construct, it is good to understand what skills and requirements are needed to bring these into play. In future blogs, we evaluate each of these against criteria. We will also evaluate few things which an application developer can do, so as make best use of Docker/Linux container technology.

Part2

No comments:

Post a Comment