Seccomp: Systemaufrufe im Kernel filtern

Seccomp (secure computing) ist eine Sicherheitsfunktion des Linux-Kernels, die den Umfang der Systemaufrufe einschränkt, die ein Prozess ausführen darf. Systemaufrufe sind die Schnittstelle zwischen Programm und Kernel – Datei öffnen, Speicher reservieren, Prozess starten, Netzwerkverbindung aufbauen. Wer hier einschränkt, nimmt einem Angreifer sehr wirkungsvoll die Werkzeuge weg.

Wie es funktioniert

Ein Prozess erhält ein Filterprogramm, das der Kernel bei jedem Systemaufruf auswertet. Der Filter ist ein kleines Programm für einen eigenen Bytcode-Interpreter (klassisch BPF). Für jeden Aufruf gibt es drei Reaktionen:

  • SCMP_ACT_ALLOW – Aufruf zulassen
  • SCMP_ACT_ERRNO – Aufruf mit Fehler ablehnen
  • SCMP_ACT_KILL_PROCESS – den Prozess sofort beenden

Der Filter kann auch Argumente prüfen, nicht nur die Rufnummer. Ein Filter kann zum Beispiel socket() grundsätzlich erlauben, aber AF_PACKET ausschließen.

Seccomp und Container

In der Container-Welt ist Seccomp eine der wichtigsten Isolationsschichten neben Namespaces, Cgroups und Capabilities. Docker, Podman und Kubernetes wenden standardmäßig ein mitgeliefertes Profil an, das rund 300 von über 400 Systemaufrufen zulässt und gefährliche ausschließt. Ein Container ist damit deutlich eingeschränkter als ein normaler Prozess auf dem Host.

# Aktives Seccomp-Profil eines Prozesses ansehen
grep Seccomp /proc/self/status      # 0=aus, 2=Filter aktiv

# Container mit eigenem Profil starten
docker run --security-opt seccomp=profil.json nginx

# In Kubernetes (SecurityContext)
securityContext:
  seccompProfile:
    type: RuntimeDefault

Vorgehen in der Praxis

Selbst Profile zu schreiben ist mühsam und fehleranfällig – ein vergessener Aufruf führt zu einem Programmabsturz, dessen Ursache schwer zu finden ist. Zwei Wege haben sich bewährt:

  1. RuntimeDefault: Das Standardprofil der Laufzeitumgebung verwenden. Es kostet nichts und schließt die gefährlichsten Aufrufe aus. In Kubernetes lässt es sich über einen Admission-Controller für alle Pods erzwingen.
  2. Profile generieren: Werkzeuge wie oci-seccomp-bpf-hook oder Inspektor Gadget protokollieren, welche Aufrufe ein Programm tatsächlich nutzt, und erzeugen daraus ein passendes Profil. Der Ausgangspunkt ist dann messbasiert statt geraten.

Wichtig ist die Grenze: Seccomp hat keine Testphase. Ein Profil, das einen nötigen Aufruf sperrt, kann nicht mehr ausgeweitet werden – der Fehler ist endgültig. Deshalb gilt: lieber etwas weniger streng beginnen und nach Messung verschärfen. Auch no_new_privs muss gesetzt sein, sonst kann ein Prozess den Filter umgehen; die Container-Laufzeiten tun das automatisch.

Verwandte Grundlagen: Linux-Capabilities, Container, AppArmor, Kubernetes.