Systeme mit Systrace härten

netbsd-execve: permit Erlaubt alle execve(2)-Aufrufe.
netbsd-execve: true then permit log Erlaubt alle execve(2)-Aufrufe und protokolliert sie an Syslog. Das »true then« ist nötig, damit »log« eingesetzt werden kann.
netbsd-fsread: filename eq "/etc/passwd" then permit Erlaubt alle Lese-Operationen auf /etc/passwd.
netbsd-fsread: filename match "/etc*" then deny [eaccess] log Verbietet alle Lese-Operationen auf /etc* mit dem Fehlercode EACCESS und protokolliert sie an Syslog.
netbsd-seteuid: uid eq "1007" or uname eq "systraced" then permit Erlaubt das Setzen der effektiven UID, wenn die UID des aufrufenden Benutzers 1007 ist oder er der Benutzer »systraced« ist.
netbsd-connect: sockaddr re "inet-.192\.168\.[0,4,8]\.[4-6].:22" then permit log Erlaubt eine Socket-Verbindung, wenn die Zieladresse des Sockets im angegebenen Adressbereich liegt. Auch dieser Aufruf wird protokolliert.

Um über einen Systemaufruf zu entscheiden, läuft Systrace durch alle Ausdrücke und bricht beim ersten Ausdruck ab, der zum Systemaufruf passt. Dieser Ausdruck entscheidet dann, ob der Systemaufruf ausgeführt oder abgelehnt wird. Wird kein passender Ausdruck gefunden, wird die Entscheidung an den Benutzer delegiert. Wird ein Systemaufruf abgelehnt, kann Systrace an das aufrufende Programm einen spezifizierten Fehlercode zurückgeben.

Um die Richtlinie auf Benutzer- bzw. Gruppenebene granulieren zu können, werden Ausdrücke mit einem Prädikat versehen. Dieses Prädikat genügt der Form ", if " {"user", "group"} {"=", "!=", "<", ">" } {Benutzername, numerische UID}. Somit lassen sich Ausdrücke der Art

netbsd-fsread: filename eq "/etc/master.passwd" then deny[eperm],
if group != wheel

erzeugen. Hier wird der Zugriff auf die Datei /etc/master.passwd mit dem Fehlercode EPERM abgelehnt, wenn der aufrufende Benutzer nicht Mitglied der Gruppe »wheel« ist.

Soll ein Systemaufruf unter anderen Benutzerrechten ausgeführt werden, kann an den Ausdruck die Direktive as user:group angehängt werden. Beispiele dazu werden im Kapitel 4 aufgeführt.

An jeden Ausdruck einer Richtlinie kann die Log-Direktive log angehängt werden. Damit wird der Ausdruck und die durch ihn implizierte Entscheidung vom Betriebssystem geloggt. Mit dieser Option lassen sich Programme komplett überwachen und analysieren. Protokolliert man beispielsweise alle exec(3)-, execve(2)- und connect(2)-Aufrufe, erfährt man, welche Programme ein Benutzer ausgeführt und welche Sockets er geöffnet hat. Beachten Sie hierbei aber unbedingt datenschutzrechtliche Bestimmungen und andere Regelungen.

Erzeugung einer Richtlinie

Ziel der Richtlinie ist es, alle erlaubten Systemaufrufe einer Anwendung zu erfassen und zu erlauben. Nicht erfasste Aufrufe sind als Angriff zu werten und zu verbieten. Somit lässt sich eine Richtlinie erstellen, indem ein spezielles Programm die zu erfassende Anwendung bei einem Probelauf überwacht und die abgesetzten Systemaufrufe mitschneidet. Die ausgeführten Systemaufrufe werden dabei in die kanonische Form normalisiert und in Richtlinien-Ausdrücke übersetzt. Existiert in der bisherigen Richtlinie kein Ausdruck, der den aktuellen Systemaufruf behandelt, wird ein neuer Ausdruck angehängt, der den Aufruf erlaubt. Manuelles Eingreifen in die erzeugte Richtlinie ist in der Regel nicht erforderlich, es sei denn, die überwachte Anwendung arbeitet mit Zufallsnamen für Dateien. Dann muss der entsprechende Ausdruck dahingehend abgeändert werden. Bei dieser automatisierten Richtlinienerstellung wird davon ausgegangen, dass das zu überwachende Programm per se sicher ist. Kann dies nicht gewährleistet werden, ist eine so erstellte Richtlinie nicht als sicher zu betrachten. Außerdem ist die Automatik ebenfalls nicht anwendbar, wenn es nicht möglich ist, alle auftretenden Code-Pfade durchzuexerzieren. Trotzdem dient eine so erstellte Richtlinie als Basis für eine händische Anpassung oder als Basis für weitere Übungsläufe. Bei diesen wird die Richtlinie nur dann erweitert, wenn neue Systemaufrufe erfolgen. Hier kann der Benutzer wieder die resultierende Aktion festlegen. Nachdem eine Richtlinie fertiggestellt wurde, kann sie von Systrace gegenüber dem gewünschten Programm durchgesetzt werden.

Implementierung

Systrace kann in einem von drei verschiedenen Modi laufen:

Initialisierungsmodus: Systrace überwacht ein Programm automatisch und generiert eine Richtlinie. Diese ist ein guter Startpunkt, um eine angepasste und verfeinerte Richtlinie zu erzeugen.
Nachfragemodus: Hier wird ebenfalls ein Programm überwacht und eine Richtlinie erzeugt, allerdings wird der Benutzer bei jedem Systemaufruf um Zustimmung gebeten. Dies ist sinnvoll, wenn dem zu überwachenden Programm nicht unbedingt von vornherein vertraut werden kann. Die Nachfrage erfolgt über das X-Programm xsystrace(1) oder im Textmodus ohne X.
Überwachungsmodus: Systrace überwacht ein Programm und setzt die definierte Richtlinie durch. Nicht erlaubte Systemaufrufe werden abgelehnt und protokolliert.

Systrace verfügt über eine Reihe von Optionen:

-A Initialisierungsmodus, erzeugt eine Richtlinie, in der alle Systemaufrufe erlaubt sind.
-a Überwachungsmodus, setzt die definierte Richtlinie durch.
-c UID:GID Spezifiziert eine numerische User- und Gruppen-ID. Unter diesen wird das zu überwachende Programm ausgeführt. Nur als Root machbar.
-d Verzeichnis Setzt ein Verzeichnis für die Richtliniendateien. Standard ist /.systrace.
-f Datei Systrace verwendet die Richtlinie, die in der Datei angegeben ist.
-g gui Aktiviert eine alternative GUI.
-i Vererbt die Richtlinie des Elternprozesses an die Kinder.
-p Systrace bindet sich an den bereits laufenden Prozess mit der angegebenen PID. Der komplette Programmpfad muss ebenfalls angegeben werden.
-t Textmodus, läuft auch ohne X.
-U Benutzt nur globale Richtlinien (/etc/systrace) statt lokaler.
-u Deaktiviert das Zusammenfassen von Systemaufrufen zu Aliasen.