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 ping nutzen
  • 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

  1. Erst alles abwerfen, dann gezielt hinzufügen: --cap-drop=ALL plus explizite Zugaben. Das ist die einzige Variante, bei der man weiß, was ein Prozess darf.
  2. Dateien mit gesetzten Capabilities sind riskant: Ein setcap auf ein Skript-Binary kann durch Umgebungsmanipulation umgangen werden. Pfade wie /usr/local/bin sollten für normale Benutzer nicht schreibbar sein.
  3. 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.
  4. 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.