Docker SecurityArchitektur und Sicherheitsfunktionen von

Containervirtualisierungen

Nils MagnusGUUG-Frühjahrsfachgespräch 2015,

Stuttgart, 26. März 2015

Jump on the Bandwagon

Docker ist Hype! Doch worum geht es da eigentlich genau?● In erster Linie keine neue Virtualisierungstechnik● Nicht wichtig, wie performant Docker ist.

Standardisierung:● einfache Schnittstelle zwischen Development und Operations ● vielleicht Katalysator für echte DevOps-Prozesse

Gretchenfrage: Wie sicher ist die Technik in der Produktion?

Vorwissen, Zielgruppe:

Systemarchitekten mit Grundlagenwissen über Dockeroder anderen Containervirtualisierungen

Docker und seine Grundlagen

Leichtgewichtige Containervirtualisierung

Greift auf Kernelfunktionen zurück, die teilweise schon ziemlich alt sind:

● LXC,● Namespaces,● Cgroups und● Layered Filesystems.

Fast alle Komponenten lassen sich austauschen.

Fühlt sich wie eine Virtualisierung an, steht aber nicht im Wettbewerb zu KVM, Xen & Co.● Vorstellbar wie eine aufgebohrte

Chroot-Umgebung● Isolation von Ressourcen● Gemeinsame Kernelnutzung

„Container 01 KMJ“ von KMJ aus der deutschsprachigen Wikipedia.

Lizenziert unter CC BY-SA 3.0 über Wikim

edia Commons

Docker ist beliebt …

… zu beliebt?

Features beeindruckend.

Sicherheit bleibt schnell außen vor:

Security außerhalb der Spielkiste vergessen

Ansatz der Docker-Entwickler:

"Protect against mistake, not abuse!"

Angriffsszenarien auf Docker

Chroot-Escape

Sniffer

Zugriff mit allen Capabilitys

Direkter Zugriff auf Block-Devices

Potentially Hostile Tenants

Secure Administration and Management

Beispiel für Chroot-Outbreak

Ausbrüche sind nicht immer offensichtlich.

Den Syscall chroot() und das gleichnamige Kommando existieren seit 1979.

Sie sind zwar nicht als Sicherheitsfunktion gedacht, erlauben aber einen Ausbruch aus dem Chroot-Jail:

#include <unistd.h>#define DIR "xxx"int main() { int i; mkdir(DIR, 0755); chroot(DIR); for (i = 0; i < 1024; i++) chdir(".."); chroot("."); execl("/bin/sh", "-i", NULL);}

Virtualisierung im Vergleich

Physikalischer Host Virtuelle Maschine Container

Gemeinsame Ressourcen

Teilen sich das Netz Teilen sich die Host-Hardware

Teilen sich den Kernel

Angriffsszenario Angriff per Netz auf offene Ports etc.

Angriff auf Hypervisor

Angriff per Syscall auf Kernel-Isolation (Namespaces, Cgroups, ...)

Schutzmaß-nahmen Portfilter, Firewalls, Segmentierung der Netze

Guter Hypervisor Absicherung im Containermanager, SE-Linux, Capabilitys

Aufwand der Maßnahmen

Einfach,Best Practices

Komplex,aber zentral zu managen

Vielschichtig durch relativ große Angriffsfläche

Isolation durch Namespaces

Sichtbarkeit nur von eigenen Prozessen, Usern, Partitionen:

$ sudo docker run -it ubuntu /bin/bash root@257b138209be:/# ps aux USER PID %CPU %MEM VSZ RSS STAT START TIME COMMANDroot 1 0.4 0.0 18176 1992 Ss 15:17 0:00 /bin/bashroot 15 0.0 0.0 15568 1132 R+ 15:17 0:00 ps auxroot@257b138209be:/# ip a[…]33: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:ac:11:00:08 brd ff:ff:ff:ff:ff:ff inet 172.17.0.8/16 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::42:acff:fe11:8/64 scope link valid_lft forever preferred_lft forever

Capabilitys

Entzug einiger Capabilitys verhindert trotz (scheinbarer) Rootrechte das Wiederherstellen des Status quo ante

# getpcaps $$Capabilities for `22424': = cap_chown,cap_dac_override, cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend+ep# docker run -it ubuntu /bin/bashroot@39ed301e0731:/# getpcaps $$Capabilities for `1': = cap_chown,cap_dac_override,cap_fowner, cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip

Gefährliches Einfallstor

Syscall-Schnittstelle ist der Eintrittspunkt in den gemeinsam genutzten Kernel

Capabilitys sind die Torwächter zu den Ressourcen der anderen Container

Innerhalb des Kernels ist das Thema komplex: Ein winziger Bug exploitet die komplette Isolation

Beispiel Shocker vom Juni 2014: Docker 0.11 (Vor-Vorgänger von 1.0) ermöglicht den Ausbruch aus dem Container

Shocker

Von Sebastian Kramer aus dem Openwall im Juni 2014 veröffentlicherter Proof-of-Concept

Docker erzeugt beim Start einen neuen Filesystem-Context und setzt per Bind-Mount neues „/“.

Container und Host nutzen innerhalb des Kernels die gleiche struct fs, um Bind-Mounts zu verwalten.

Wer kennt den Syscall open_by_handle_at()? Dazu braucht man die CAP_DAC_OVERRIDE, die Docker damals hatte.

Mit diesen Berechtigungen konnte man in den Inodes des Hosts suchen und dort z. B. dessen /etc/shadow lesen.

Lokale Ressourcen

Was lässt sich schützen?

Bei Zugriff auf Kernel: nichts Bei Zugriff auf Hardware: wenig

Nicht vergessen:Zugriff vom Host ist zwangsläufig immer möglich!

In Multi-Tenant-Umgebungen ist das durchaus eine wichtige Überlegung!

Docker im Einsatz

Sehr praktisch und ein Erfolgsfaktor für Docker:Der Docker-Hub/Registry. Doch: Woher kommen die Images? Malicious Images erhalten Zugriff auf

Host-System (vor Docker 1.3.3) Wer paketiert nach welchen Kriterien?

Diese Überlegung gilt für sämtliche Fremd-Software (Open Source + proprietär)!

Keine Passwörter, Zertifikate, Credentials oder Unter- nehmensgeheimnisse in Container coden und uploaden!

Netzwerk-Sicherheit

Üblicherweise hängen alle Container an einer Bridge

alle Container sind in einem Segment: keine besondere netztechnische Trennung zwischen Containern

Host-Firewall reicht nicht aus:

Clustermanagement: (Etcd etc.) Kommunikation zwischen Nodes muss vertraulich und authentisch sein (kein Default)

HostInternet Cont. 1 Cont. 4Cont. 2 Cont. 3

Architektonische Kritik am Daemon

Docker verwaltet alle Container-Operationen über einen dauerhaften Daemon mit REST-Schnittstelle

Nutzt normalerweise einen Unix-Domain-Socket

Mit Option -H lässt sich der Daemon an einen TCP-Port binden. Das braucht man für die Orchestrierung.

Gefährlich, wenn dieser Port extern erreichbar ist.

Nicht alle Verbindungen per Default verschlüsselt

Kritiker entwerfen neues Projekt Rocket,steckt aber noch in den Kinderschuhen.

Empfehlungen extern (für den Host)

Nicht nur auf ein Pferd setzen: Mehrere Layer Security

AppArmor sichert Zugriff auf Dateien und Pfade.

Profil für SE-Linux trennt Host von Container

Labels und Profiles gibt’s schon fertig, sind aber trickreich im Detail

Pro Umgebung, Context oder Tenant ein separater Host

Einsatz von Seccomp als eine Art Syscall-Firewall

Allgemeines Kernel-Hardening mittels Grsecurity

Empfehlungen intern (für den Container)

Patchmanagement auch für Images bedenken (entsprechende Zeilen im Dockerfile)

Nur eine Anwendung pro Container

Trotz Container Least Privilege beachten

kein SSH in den Container erlauben

saubere Datenpfade (Vorsicht bei Volumes, die gesharte Verzeichnisse vom Host oder anderen Containern mounten)

Wrap-up

Architektur und Technik von Docker:Faszinierend, aber gefährlich komplex

Namespaces, Capabilitys, Syscalls isolieren lokal

Networking und Orchestrierung bieten noch Herausforderungen

Es gibt keine konzeptionell-inhärente Probleme, die gegen Docker sprechen

Methoden, um Probleme abzusichern, existieren!

Fragen.Sie.

Jetzt!

Vielen Dank für Ihre Aufmerksamkeit!

Kontakt

Nils MagnusSenior Systems Engineer

inovex GmbHOffice MünchenValentin-Linhof Str. 281829 München

Mobil: +49-173-3181-057E-Mail: nils.magnus@inovex.de

Sprechen Sie uns an aufunsere Referenzprojekte!