Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Docker Security

1,389 views

Published on

Introduction to common docker security issues. Originally presented at Rochester 2600. http://www.rochester2600.com

Published in: Technology
  • Be the first to comment

Docker Security

  1. 1. Docker Security Specific reasons why Docker sucks
  2. 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.
  3. 3. 1970-80’s: Mainframes The Application
  4. 4. 1980-90’s: Thick Apps App App App App App App App
  5. 5. 1990-00’s: Segregation App App App App App App App
  6. 6. 2000’s: Virtualization (Same) App App App App
  7. 7. 2000-2010’s: The Cloud Your app Your app Some one else’s app
  8. 8. Today: Containers Your app Your app Your app Your app Your app Your app Your app Your app Not Your app Not Your app Not Your app Not Your app Your app Your app Your app Your app Your app Your app Your app Your app Your app Your app Your app Your app Your app
  9. 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
  10. 10. Example 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
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. “However, for those that depend on VMs for security, Docker is not an alternative, but a complement” @ewindisch – Cloud pioneer
  26. 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. 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. 28. “Fuck Docker” - Jason Secure, but not by default

×