This document discusses the security aspects of containers compared to virtual machines. While containers provide better performance through thin isolation layers, this reduces security compared to fully virtualized systems. Containers run applications with full access to the host operating system's kernel and have limited isolation of things like devices and modules. The document recommends treating container security like a networked server by running as non-root users, using tools like SELinux for additional isolation, and only using trusted container images. Backing containers with security features of the Linux kernel like capabilities and seccomp can also help restrict what containers can access.

1. CONTAINERS
&
SECURITY
Sri Rajan

2. Container Recap
Host OS
Hypervisor
App A
Binaries
Guest OS
(Windows)
App B
Binaries
Guest OS
(Linux)
Host OS
Container
Engine
App A
Binaries
OS Image
(Ubuntu)
App B
Binaries
OS image
(Red Hat)
The same Host Kernel
VM CONTAINER

3. Container Recap - Building Blocks
• Pid
• Mnt
• Net
• Memory
• Cpu
• Blkio
Docker
libcontainer
lxc libvirt
• Ipc
• Uts
• User
Namespaces (Think isolation)
Linux
Cgroups (Think Limits)

4. What is more
secure?
Powered off server
Air gapped Server
Networked Server
Virtualized Server
Containers on a Server
In that order !!!

5. Containers don’t really “contain”
- Daniel J Walsh (Red Hat)
From a security perspective

6. Why?
• The very thin layer of isolation that provides better
performance also reduces security
• Container daemon runs as root

7. Why?
• Not everything is namespaced
• /dev/sd*
• modules
• Containers have full access to
• /sys, /sys/fs
• /proc/*

8. Image trust
• Source of images
• A recent automated study of images available in
the public Docker showed that 30% of images
contained serious security vulnerabilities.
Source: http://www.banyanops.com/blog/analyzing-docker-hub/

9. The Human Element
• Developers like love containers because they can
package their application (Build...Ship…Run)
• Operations appreciate containers because they
get packaged applications to run
• Who actually owns the security?

10. What now?

11. Back to some basics
• Treat a container like you would treat running
Apache on a server
• User perms
• Run as non-root
• Treat root inside the container as root outside
• docker run --privileged=false centos
/bin/bash

12. Back to some basics
• Worry about your Kernel
• Who is providing patches?
• Grsec kernels
• https://grsecurity.net/

13. Back to some basics
• Worry about your Images (Docker)
• Trust only vendor supplied ones
• Build your own
• Use Dockerfiles
• Please don’t run RHEL 4 images !!!

14. Namespaces
• Can be limited !
docker run --pid=host rhel7 strace -p 1234

15. SeLinux
• SeLinux policies can
• Isolate containers from the host
• Isolate containers from other containers
• docker run --security-opt
label:type:svirt_apache_t –it centos
/bin/bash

16. Seccomp
• Secure computing mode (Developed by Google)
• Removessyscalls from a process
• docker run -d --security-opt
seccomp:allow:clock_adjtime ntpd
• 4.1 kernel has 378 syscalls !
• Strace/ptrace
• If your app needs full control of kernel
• Containers are not the best fit
• Containers are not going to make it secure

17. Linux Capabilities
• Setuid was a problem
• 2.2 Kernel introduced capabilities
• http://linux.die.net/man/7/capabilities
• Breaks the power of root !
• Eg. CAP_NET_RAW (can be set for /bin/ping)
• 32 possible values
• docker run --cap-drop ALL --cap-add SYS_TIME
ntpd /bin/sh

18. Some other techniques
• Super privileged containers
• --readonly containers
• Root file system is read only

19. THANK YOU
https://pollev.com/raxtech

20. References & Links
• ftp://www.kernel.org/pub/linux/libs/security/linux-­privs/kernel-­2.2/capfaq-­
0.2.txt
• http://opensource.com/business/15/3/docker-­security-­tuning
• https://grsecurity.net/
• http://www.cyberciti.biz/tips/selinux-­vs-­apparmor-­vs-­grsecurity.html
• http://developerblog.redhat.com/2014/11/06/introducing-­a-­super-­privileged-­
container-­concept/
• http://opensource.com/business/14/7/docker-­security-­selinux