Open Source im professionellen Einsatz
Linux-Magazin 01/2003

Systrace setzt Regeln für erlaubte Systemaufrufe durch

Enges Korsett

,

Ob Webserver, Browser, IRC-Client oder Audioplayer: Sicherheitslücken in Clients und Servern führen dazu, dass die Programme schädliche Aktionen ausführen können. Systrace verhindert diese Folgen - es zwängt die Applikation in ein eng geschnürtes Korsett von erlaubten Sytemaufrufen.

568

Der Kernel-Pförtner Systrace zwingt Prozesse, sich an eine Policy (ein Regelwerk) für ihre Systemaufrufe zu halten, und schränkt damit den Zugriff auf den Host ein. Das verhindert zwar keine Sicherheitslücken, vermindert aber deren Folgen: Wenn ein Programm keine weiteren Prozesse starten muss, sperrt die Systrace-Policy den dazu nötigen Syscall. Ein Eindringling kann so keine Shell aufrufen, selbst wenn er einen Prozess vollständig kontrolliert.

Um die Policy durchzusetzen, fängt Systrace die Systemaufrufe im Kernel ab und führt nur die vorgesehenen Funktionen tatsächlich aus. Wenn eine Applikation versucht, außerhalb ihrer Grenzen zu arbeiten, warnt ein GUI den Anwender und fordert ihn dazu auf, die Aktion zu erlauben oder zu verbieten. Systrace besteht aus einem Kernel-Patch, einem Kommandozeilen-Programm und einem Gtk-GUI (BSD-lizenziert). Alle drei Komponenten sind auf[1] erhältlich.

Über Systemcalls erhalten Userspace-Applikationen Zugang zum Kernel. Systemaufrufe bieten Dienste in sicherheitskritischen Bereichen an, etwa beim Umgang mit Dateien, Netzwerkverbindungen oder Heap-Speicher. Tabelle 1 zeigt eine Übersicht gängiger Syscalls - die meisten Unix-ähnlichen Betriebssysteme kennen über 200 dieser Aufrufe. Nur über sie sind dauerhafte Änderungen am System möglich. Ohne sie könnte ein Prozess keine sinnvollen Aufgaben erfüllen, ein Angreifer könnte aber auch keinen Schaden anrichten.

Tabelle 1: Gängige Systemcalls

Kein Angriff ohne Syscall

Ein typischer Angriff gelingt zum Beispiel durch einen Buffer Overflow in einem Webserver, durch den der Eindringling Shell-Zugang erhält. Der Cracker wird Exploit-Code einschleusen, der dann mit den Rechten des Webserver-Prozesses abläuft. Dieser Code muss einige Systemcalls ausführen, beispielsweise »fork()« und »execve()«, um die Shell zu starten. Erst durch Syscalls haben Lücken schädliche Folgen. Da sich Sicherheitslücken nicht vermeiden lassen, bietet sich das Überwachen von Systemaufrufen an, um einen Schutz zu implementieren.

Im Normalfall kann eine Applikation alle Systemcalls aufrufen. Nichts hindert den Webserver daran, einen Shell-Prozess auszuführen und jedem User bereitzustellen, der eine Verbindung zum Webserver aufbaut. Diese Aktion ist aber nicht vorgesehen und der Server ist auch nicht dafür programmiert. Durch Software-Bugs können Angreifer die Applikation jedoch dazu verleiten, Aktionen auszuführen, die von den Autoren nicht vorgesehen wurden.

Jede Applikation benötigt für ihre Aufgaben nur einen Teil der Syscall-Schnittstelle. Ein einfacher Webserver hört auf TCP-Port 80, beantwortet HTTP-Requests und stellt Dateien aus einer Standard-Verzeichnisstruktur bereit. Weitere Dienste muss er nicht anbieten, insbesondere muss er keine interaktive Shell starten oder »/etc/passwd« lesen.

Der erwünschte Funktionsumfang eines Programms lässt sich anhand seiner Systemaufrufe beschreiben. Systrace nutzt dies: Es beobachtet die Syscalls und leitet daraus eine passende Richtlinie ab. Unter der Kontrolle von Systrace kann die Applikation dann nur noch innerhalb der Policy arbeiten.

Richtlinien

Eine Systrace-Policy besteht aus einer Reihe von Regeln. Jede Regel gilt für einen Syscall sowie seine Parameter und legt fest, ob dieser Aufruf erlaubt ist oder nicht. Die folgenden einfachen Richtlinien erlauben die System-Calls »fchdir()« und »fstat()«:

linux-fchdir: permit
linux-fstat: permit


Die Anweisung »deny« an Stelle von »permit« würde diese Systemaufrufe unterbinden. Die Regeln können sich auch nur auf bestimmte Parameter des Syscalls beziehen:

linux-fsread: filename eq "/tmp/foo" then permit
linux-fsread: filename match "/etc/*" then deny[enoent]


Das Programm darf nach diesen Regeln die Datei »/tmp/foo« lesen. Files, deren Name auf das Muster »/etc/*« passt, führen dagegen zu einem »ENOENT«-Fehler. Statt den Syscall auszuführen, signalisiert Systrace damit der Anwendung, dass die Datei nicht existiert.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Doppelgänger

    Die kommende Release 11 von Solaris kann mit Zones eine Linux-Serverumgebung emulieren. In dem freien Entwicklungszweig Open Solaris lässt sich die neue Technologie bereits ausprobieren. Dieser Workshop liefert einen Überblick und gibt Ihnen Tipps zur Installation.

  • Allgemeine Schutzimpfung

    Gelingt es einem Angreifer, fremde Systeme zu infizieren, erbt er alle Rechte seiner Opfer. App Armor schützt vor den Folgen, indem es die Rechte potenzieller Opfer auf ein Minimum begrenzt. Selbst bei einem Webserver mit PHP-Applikationen trennt App Armor scharf zwischen den Sitzungen.

  • Großer Auftakt

    Gängige Intrusion-Detection-Systeme beobachten nur den einzelnen Rechner (Host-IDS) oder nur das Netzwerk (NIDS). Zusammengenommen versprechen die Sensordaten aber bessere Informationen über Eindringlinge. Das Open-Source-IDS Prelude ist HIDS und NIDS zugleich.

  • OpenSSH 5.9 mit Sandboxes

    Die freie SSH-Implementierung OpenSSH bietet in Version 5.9 verschiedene Sandbox-Techniken für mehr Sicherheit an.

  • Kern-Technik

    Systemaufrufe bilden die Schnittstelle zwischen Userspace und Kernel. Dieser Artikel zeigt, wie sie funktionieren und wie man sogar eigene Systemcalls implementiert.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.