GUUG-Frühjahrsfachgespräch Speaker: Nils Magnus, inovex GmbH Mehr Vorträge von uns: https://www.inovex.de/de/content-pool/vortraege/

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.
●
Vorstellbar wie eine aufgebohrte
Chroot-Umgebung
●
Isolation von Ressourcen
●
Gemeinsame Kernelnutzung
„Container 01 KM
J“ von KM
J aus der deutschsprachigen W
ikipedia.
Lizenziert unter CC BY-SA 3.0 über W
ikimediaCommons

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 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);
}

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 1 0.4 0.0 18176 1992 Ss 15:17 0:00 /bin/bash
root 15 0.0 0.0 15568 1132 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 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

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

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. 2
81829 München
Mobil: +49-173-3181-057
E-Mail: nils.magnus@inovex.de
Sprechen Sie uns an auf
unsere Referenzprojekte!