Linux-Capabilities sind ein Berechtigungskonzept, das die Alles-oder-nichts-Logik von root aufbricht. Statt einem Prozess entweder volle Systemrechte oder gar keine zu geben, verteilt der Kernel rund vierzig einzelne Befugnisse – jede für genau eine Fähigkeit. Das ist die sicherheitstechnisch wichtigste Grundlage des Container-Betriebs.
Warum das Konzept existiert
Klassisch galt: Nur root darf einen Port unter 1024 binden, Netzwerkkonfiguration ändern, Systemzeit setzen, Kernelmodule laden oder Prozesse anderer Benutzer steuern. Ein Programm, das einen dieser Vorgänge brauchte, musste als root laufen – und hatte dann alle Rechte. Ein Fehler in einem Netzwerkdienst konnte damit das ganze System gefährden.
Capabilities schneiden das zu: Ein Webserver kann CAP_NET_BIND_SERVICE erhalten, um Port 80 zu binden, und läuft ansonsten als unprivilegierter Benutzer.
Wichtige Capabilities
- CAP_NET_BIND_SERVICE: Ports unter 1024 binden
- CAP_NET_ADMIN: Netzwerkschnittstellen, Routen, Firewall-Regeln konfigurieren
- CAP_NET_RAW: Raw-Sockets und damit unter anderem
pingnutzen - CAP_SYS_ADMIN: Mounts, Namespaces und vieles mehr – faktisch nahe an root und deshalb möglichst zu vermeiden
- CAP_SYS_TIME: Systemuhr stellen
- CAP_CHOWN: Dateieigentümer ändern
- CAP_KILL: Signale an fremde Prozesse senden
- CAP_DAC_OVERRIDE: Dateirechte des Dateisystems umgehen
Der Kernel prüft bei jedem privilegierten Vorgang, ob die passende Capability gesetzt ist. Ein Prozess besitzt mehrere Sätze davon: Permitted (erlaubt), Effective (aktuell wirksam), Inheritable (vererbbar) und Ambient (an neue Programme weitergegeben).
Im Alltag
# Capabilities einer Datei ansehen und setzen
getcap /usr/bin/ping
setcap cap_net_raw+ep /usr/bin/mein-ping
# Capabilities eines laufenden Prozesses
grep Cap /proc/self/status
# Container mit genau einer Capability starten
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx
# In Kubernetes
securityContext:
capabilities:
drop: ["ALL"]
add: ["NET_BIND_SERVICE"]
Grundregeln
- Erst alles abwerfen, dann gezielt hinzufügen:
--cap-drop=ALLplus explizite Zugaben. Das ist die einzige Variante, bei der man weiß, was ein Prozess darf. - Dateien mit gesetzten Capabilities sind riskant: Ein
setcapauf ein Skript-Binary kann durch Umgebungsmanipulation umgangen werden. Pfade wie/usr/local/binsollten für normale Benutzer nicht schreibbar sein. - CAP_SYS_ADMIN vermeiden: Wer es braucht, sollte prüfen, ob nicht eine andere Capability genügt. In vielen Container-Setups ist es der eigentliche Sicherheitsverlust.
- Rootless bedeutet nicht rechtelos: In einem benutzerlosen Container erhält der Nutzer innerhalb des Namespace zwar root-ähnliche Rechte, aber ohne Capabilities über den Namespace hinaus – das ist der entscheidende Schutz.
Capabilities ergänzen die anderen Schichten der Isolation: Seccomp filtert Systemaufrufe, AppArmor und SELinux beschränken Dateizugriffe, Cgroups begrenzen Ressourcen. Erst die Kombination ergibt einen belastbaren Schutz.
Verwandte Grundlagen: Seccomp, Container, Autorisierung, Kubernetes.