Workshop: Linux-Hardening

Aus der Praxis

Ein Prozess mit Root-Rechten (privilegierter Prozess), der vollen Zugriff auf das Dateisystem hat und an keine Prozesslimits stößt, ist für viele Applikationsentwickler der Idealfall. So braucht man sich im Vorfeld keine Gedanken über Zugriffsrechte und Isolation zu machen.

Allerdings gibt es dafür eine Reihe von Nachteilen:

• Ressourcen: Jedem Prozess werden standardmäßig nur begrenzte Ressourcen (etwa Speichernutzung, Datei-Handles oder Rechenzeit) zugewiesen, die sich per "ulimit" ansehen und modifizieren lassen. Die Softlimits lassen sich bis zum Hardlimit ausreizen, und viele Werte sehen als Vorgabe "unlimited", also nicht begrenzt, vor. Als Benutzer mit Root-Rechten kann man aber auch die Hardlimits entsprechend mit zum Systemmaximum inkrementieren, sodass eine eigentliche Begrenzung für das System nicht mehr zum Tragen kommt.

• Dateisystem - reservierte Blöcke: Die meisten Dateisysteme reservieren eine Anzahl an Blöcken für Prozesse mit der Benutzer-ID 0. Ein nicht privilegierter Prozess sollte also niemals in der Lage sein, ein Dateisystem zu 100 Prozent zu füllen, wenn diese Reserve vorhanden ist. Ein Prozess, der mit Root-Rechten gestartet wurde und diese auch nicht verändert, kann diese reservierten Blöcke ebenfalls nutzen, was ein Eingreifen des Systemadministrators massiv erschwert, da im Dateisystem kein freier Platz mehr vorhanden ist, der für einen normalen Betrieb notwendig wäre.

• Dateisystem - Quota: Mit Quota bezeichnet man ein Accounting für die Nutzung von Dateiblöcken und I-Nodes pro Benutzer- und Gruppen-ID. Es wird auch hier nach Soft- und Hardlimits differenziert, wobei Letzteres nach dem Überschreiten des (größeren) Softlimits für eine vorgegebene Zeit zur Anwendung kommt.

• Zwar lassen sich auch für den User "Root"-Quotalimits auf Dateisystemebene setzen, aber wenn eine Datei keinem definierten Benutzer oder Daemon-Account zugeordnet wurde, ist der Eigentümer meist "Root", und damit fallen dann sehr viele Dateien unter das Accounting. Von daher betrachtet empfiehlt es sich kaum, dieses Limit zu setzen.

• Zugriffsrechte: Der Prozess mit der Benutzer-ID 0 hat auch vollen Zugriff auf alle lokalen Dateisysteme, kann daher leicht vieles löschen, Prozesse starten oder beenden. Die klassische Zugriffkontrolle mit "Root darf alles", ist daher ein Risiko. Eine erweiterte Zugriffskontrolle, wie beispielsweise bei Security Enhanced Linux (SELinux) oder AppArmore, bietet hier auch die Möglichkeit, diese Zugriffe zu kontrollieren. Allgemein sollten Prozesse, wann immer möglich, nicht mit den vollen Rechten im System (UID und/ oder GID=0) aktiv sein. Denn sollte es einem anderen Prozess oder Benutzer möglich sein, über den privilegierten Prozess Aktionen auszuführen, so erfolgt dies ohne Restriktionen. Dies wird noch oft beim sogenannten Buffer-Overflow, das heißt dem Überschreiben von Daten und Ausführen von Programmcode auf dem Stack, ausgenutzt.