Docker Security. Architektur und Sicherheitsfunktionen von Containervirtualisierungen

Transkript

1 Docker Security Architektur und Sicherheitsfunktionen von Containervirtualisierungen Nils Magnus GUUG-Frühjahrsfachgespräch 2015, Stuttgart, 26. März 2015

2 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 Docker oder anderen Containervirtualisierungen

3 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. Container 01 KMJ von KMJ aus der deutschsprachigen Wikipedia. Lizenziert unter CC BY-SA 3.0 über Wikimedia Commons Vorstellbar wie eine aufgebohrte Chroot-Umgebung Isolation von Ressourcen Gemeinsame Kernelnutzung

4 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!"

5 Angriffsszenarien auf Docker Chroot-Escape Sniffer Zugriff mit allen Capabilitys Direkter Zugriff auf Block-Devices Potentially Hostile Tenants Secure Administration and Management

6 Beispiel für Chroot-Outbreak Ausbrüche sind nicht immer offensichtlich. Den Syscall chroot() und das gleichnamige Kommando existieren seit 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); }

7 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

8 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 COMMAND root Ss 15:17 0:00 /bin/bash root R+ 15:17 0:00 ps aux root@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 /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

9 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_ne t_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,c ap_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,c ap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_sy slog,cap_wake_alarm,cap_block_suspend+ep # docker run -it ubuntu /bin/bash root@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

10 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

11 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.

12 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!

13 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 Unternehmensgeheimnisse in Container coden und uploaden!

14 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: Internet Host Cont. 1 Cont. 2 Cont. 3 Cont. 4 Clustermanagement: (Etcd etc.) Kommunikation zwischen Nodes muss vertraulich und authentisch sein (kein Default)

15 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.

16 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

17 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)

18 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!

19 Fragen. Sie. Jetzt!

20 Vielen Dank für Ihre Aufmerksamkeit! Kontakt Nils Magnus Senior Systems Engineer inovex GmbH Office München Valentin-Linhof Str München Sprechen Sie uns an auf unsere Referenzprojekte! Mobil: nils.magnus@inovex.de