![Background: AppArmor
• Linux Security Module
• Second line of defense for containers
• Restrict various actions based on a policy
• Example: Mounting
• Block access to /dev/pts so a container can’t read a
host’s terminal
deny mount fstype=devpts
• Example: Utility access
• Block access to /proc/sys/kernel/modprobe so that
attackers can’t replace it with arbitrary code
deny /proc/sys/kerne[^l]*{,/**} wklx,](https://image.slidesharecdn.com/dockersecurity-redacted-160706161847/85/Docker-Security-15-320.jpg)
Docker Security
- 1. Docker Security Specific reasons why Docker sucks
- 2. Disclaimer: I’m using Docker wrong Let this presentation be a discussion of Docker, it’s threat model, and security concerns and not a recommendation of how you should use docker. All examples of using docker in this presentation are exactly opposite of how you should be using docker. If you’re interested in microservices on your internal network, testing out applications, or developing applications for a San Francisco startup, docker may be a perfect solution. If you just want to run a website, containers do have a substantial benefit.
- 4. 1980-90’s: Thick Apps App App App App App App App
- 9. Containers today vs yesterday Today • Disposable • “I don’t care if I’m hacked, I’ll just rebuild” – Jason • Low profile • Unikernels take up MB’s not GB’s • Scalable Yesterday • Very important • DON’T TOUCH THAT SERVER OMG DOWNTIME • High resources: • “Fuck it, just install QT” • Not scalable
- 11. Containers vs VMs • Containers ~= chroot (on meth) • Think virtual environment • They have much lower overhead than VMs (micro/unikernels) • Fast but they are not hardware backed virtualization • Namespaced process separation not true isolation • They really have nothing to do with VMs • Why are we even comparing them to VMs? This slide is stupid
- 12. Container Security • Containers have been around for decades but not for security • Docker made containers popular and sexy • Oh wait, security? Fuck it, move to production • But why are they insecure?
- 13. Background: Namespaces • Creates a logical separation of resources • Namespaces are the core of containers • Types of namespaces: • Network: isolated network stack • Mount: namespaced mount points • UID/PID: namespace isolation of process and user ID’s (root inside does not mean root outside) • Cgroups: controls for shared resources
- 14. Background: Capabilities • A capability is a *nix action a user can perform • Goal is to restrict “capabilities” • Privileged process = all the capabilities! • Unprivileged process = check individual user capabilities • Example Capabilities: • CAP_CHOWN • CAP_SETUID • CAP_NET_RAW • CAP_SYS_RAWIO
- 15. Background: AppArmor • Linux Security Module • Second line of defense for containers • Restrict various actions based on a policy • Example: Mounting • Block access to /dev/pts so a container can’t read a host’s terminal deny mount fstype=devpts • Example: Utility access • Block access to /proc/sys/kernel/modprobe so that attackers can’t replace it with arbitrary code deny /proc/sys/kerne[^l]*{,/**} wklx,
- 16. Background: Seccomp • Restricts system calls based on a policy • Block things like • Kernel manipulation (init_module, finit_module, delete_module) • Executing mount options • Setting the system time • Reboot • Blacklist based • Same technology that Subgraph bases their container protections on
- 17. The Root Threat A privileged container – one that is running with root privs -- is your biggest threat to the host computer • Think of all the attack vectors your container could have access to • Mounted volumes • Logging resources, scheduled tasks • Kernel drivers • Shared devices
- 18. 1. RW Volume Abuse • Containers allow you to mount a host volume inside of a container docker run -it -v /usr/local/bin:/bin apache • When root is always root – if the container is exploited, they will have root access to the above host system. • Defense: • Don’t be an idiot • Make sure that your images are all unprivileged • This is why it’s so important to run unprivileged containers
- 19. 2. Docker socket control • Some containers will mount the Docker socket so it can control other containers docker run -it –v /var/run/docker.sock:/var/run/docker.sock bash apt-get install docker • The container docker can control the host docker now • From there we can run a docker container in the host and priv esc to root • Defense: • Never mount the docker sock into the container
- 20. 3. Device sharing • Docker supports directly passing a device into a container • USB devices, bladeRF, whatever docker run –it –-device=/dev/sda bash • That container has full access to do whatever it wants to the device. • Reformat, inject commands, modify binaries, etc • Defense: • Don’t mount shared devices directly • Never run privileged containers
- 21. 4. Shared Networking Exploits • Containers have a shared bridge interface named docker0 with an individually namespaced network stack • The bridge interface docker0 will forward any packets back up to eth0 • By default all containers include the NET_RAW capability • Result: A container can ARP poison entire network segments and other containers • Defense: • Manually drop the NET_RAW capability • Setup iptables rules to prevent these types of attacks • Use third party tools to manage networking
- 22. Honorable Mentions • 5. Kernel exploitation • 6. LXC 0-day • 7. Owning a service on the Docker Hub • 8. Docker service runs as HTTP by default • 9. Docker service does not verify TLS certificates by default • 10. Sensitive environment variable leakage
- 23. Recently Patched Examples • Privileged: SYS_RAWIO abuse (LXC only) exploits unnecessary capabilities to get direct access to PCI devices • Privileged: Ptrace(2) lets a container bypass seccomp-bpf policies because of a TOCTTOU issue • Unprivileged: PID namespace info-leak of /proc/sched_debug contains namespace- unaware info to find other containers running
- 24. How to secure docker • Never run privileged containers! • AppArmor and Seccomp-bpf profiles • Defaults are good enough • Custom policies for your container would be even better • GRSEC/PAX: Last line of defense in the case of a kernel exploit
- 25. “However, for those that depend on VMs for security, Docker is not an alternative, but a complement” @ewindisch – Cloud pioneer
- 26. Much security such wow Bsidesroc.com wordpress Antitree.com wordpress Joethecoolestguyontheinternet.com Jwilder/nginx-proxy Antitree.com MySQL Bsidesroc.com MySQL Static HTML Jrcs/lets-encrypt-nginx-proxy-companion 443/TCP 443/TCP 443/TCP 443/TCP briancranston 9030/TCP $3.29/mo $3.29/mo $3.29/mo $3.29/mo $3.29/mo
- 27. Y U CONTAINER? Bsidesroc.com wordpress Antitree.com wordpress Joethecoolestguyontheinternet.com Jwilder/nginx-proxy Antitree.com MySQL Bsidesroc.com MySQL Static HTML Jrcs/lets-encrypt-nginx-proxy-companion 443/TCP 443/TCP 443/TCP 443/TCP briancranston 9030/TCP $3.29/mo $3.29/mo $3.29/mo $3.29/mo $3.29/mo
- 28. “Fuck Docker” - Jason Secure, but not by default