Open Source im professionellen Einsatz

Workshop: Sicheres Programmieren für Administratoren - Folge 2

Wurzelbehandlung

Dominik Vogt

Fast jedes Skript oder Programm öffnet und bearbeitet Dateien. Dieser Workshop zeigt, wo die Gefahren lauern, und erklärt Admins und Entwicklern, wie sie Fehler schon an der Wurzel neutralisieren.

Zahlreiche Fallen für den programmierenden Admin verbergen sich in ganz unschuldig aussehenden Dateioperationen, etwa ein File erzeugen, öffnen oder schließen. Teil 1 dieser Serie[1] hat bereits offene Dateien bei Programmstart und -ende behandelt; diese Folge gibt Hinweise, wie man weitere Operationen auf dem Dateisystem mit C, C++ und Shellskripten zähmt.

Die Wurzel des Übels

Unix ordnet Dateisysteme, Geräte und andere Ressourcen unterhalb des Wurzelverzeichnisses in einen Verzeichnisbaum ein, auf den viele Prozesse gleichzeitig zugreifen dürfen. Diese Parallel-Zugriffe führen oft zu so genannten Race Conditions, die sich als Sicherheitslücke manifestieren (siehe Kasten "Symlinks, Races und deren Folge").

Listing 1: Symlink-Schwäche
01 #!/bin/sh 02 for i in `find . -name "*.txt"`; do 03 tr "A-Z" "a-z" < $i > /tmp/unsicher.tmp 04 mv /tmp/unsicher.tmp $i 05 done

Race Conditions treten ein, wenn ein Programm oder Skript davon ausgeht, dass sich seine Umgebung nicht verändert. Während er mit Dateien hantiert, kann ein Prozess aber allerlei Überraschungen erleben: Zwischen zwei Einzelaktionen erzeugt vielleicht ein anderer Prozess eine neue Datei oder ein Verzeichnis, löscht oder verschiebt es, der Admin hängt ein Dateisystem ein oder aus (»mount()«, »umount()«), ändert den Besitzer einer Datei, ein Benutzer hängt einen symbolischen Link um, erzeugt oder löscht einen Hardlink oder ändert die Rechte einer Datei.

Namensfrage

Verwundbar sind vor allem Programme und Skripte, die sorglos mit Dateinamen werkeln. Kein gängiges Dateisystem garantiert, dass ein Name sich zu zwei verschiedenen Zeitpunkten auf denselben Inode bezieht. Dabei riskiert der Programmierer dreierlei:

Er operiert mit einer anderen Datei als beabsichtigt.
Eigenschaften der Datei ändern sich unerwartet.
Ein Benutzer oder ein Prozess erhält andere Zugriffsrechte
als gewollt.

Ganz zu verhindern sind solche Pannen auch nicht durch scharfe Sicherheitsmaßnahmen, doch sollte der Entwickler sein Programm darauf vorbereiten. Bei der Abwehr darf er immerhin davon ausgehen, dass Root gefährliche Situationen nicht absichtlich herbeiführt.