Linux goes Cloud

Ubuntu 10.10 Maverick Meerkat Server im Test

12.02.2011
Von 
Jürgen Donauer war als Systemadministrator zunächst für Informix und später IBM tätig. Dann verschlug es ihn in das Rechenzentrum von Media-Saturn. Dort kümmerte er sich mitunter um die Webserver, Datenbankanbindungen und den Online-Shop. Anschließend war er als Redakteur im Bereich Linux für TecChannel tätig.

Linux Kernel bringt mehr Sicherheit

Ubuntu 10.10 Maverick Meerkat bringt Linux-Kernel 2.6.35 mit sich. Wegen der wachsenden Popularität von Linux, könnte das Open-Source-Betriebssystem in der Zukunft auch ein Angriffsziel werden. Aus diesem Grund versuchen die Kernel-Entwickler die Schutzmaßnahmen auszubauen. In Maverick sind daher drei nennenswerte Änderungen vorhanden, die das Herzstück abhärten.

ptrace-Schutz

Eine störende Schwäche der Linux-Prozess-Schnittstelle ist, dass ein einzelner Anwender den Speicher und die Stati der Prozesse untersuchen kann. Würde ein Angreifer zum Beispiel Firefox kompromittieren, könnte er dadurch weitere Daten von laufenden Prozessen, wie etw gpg-agent, auslesen. Somit ließe sich der Bereich des Angriffs ausweiten.

Laut Ubuntu ist dies kein theoretisches Problem. SSH-Session-Hijacking und sogar Einspeisung beliebigen Codes seien komplett möglich, wenn ptrace im Normalstatus läuft. Aus diesem Grund verwenden einige Applikationen prctl(), um ptrace-Anhänge explizit zu verbieten. Ein generellerer Lösungsansatz ist, ptrace nur direkt vom Eltern-Prozess zu den Kind-Prozessen zu erlauben.

Das Verhalten kontrolliert der sysctl-Werin /proc/sys/kernel/yama/ptrace_scope. Der Standard ist 1, um Nicht-Kind-Prozesse zu blockieren. Setzt man diesen Wert auf 0 zurück, erlaubt das System wieder mehr. Auf einigen Entwicklungs-Rechnern oder Computern mit lediglich einem Administrator-Konto könnte diese Einstellung die zu bevorzugende sein.

Symlink-Schutz

Seit geraumer Zeit ist die TocToU-Rally ein Sicherheits-Problem. Meistens steht es im Zusammenhang mit Verzeichnissen mit Allerwelts-Rechten, wie zum Beispiel /tmp/. Diese Schwachstelle wird normalerweise so ausgenutzt, dass Angreifer die Rechte-Grenzen überschreiten können, indem sie einem symbolischen Link folgen.

Die Lösung hier ist, dass man in Verzeichnissen, die dem ganzen System zur Verfügung stehen, das Folgen von Symlinks nur dann erlaubt, wenn der Anwender übereinstimmt. Einige Gegner argumentieren, dass dies POSIX verletze. Die Ubuntu-Entwickler sind aber der Meinung, dass man bei POSIX nicht über diese Sicherheitslücke nachgedacht habe. Diese Spezifikation auf Kosten der Sicherheit einzuhalten sei nicht tragbar. Ebenso gelten die Argumente „Es könne unbekannte Anwendungen nicht lauffähig halten, die diese Funktion benutzen“ und „Applikationen sollten einfach mkstemp() oder 0_CREATE|0_EXCL benutzen“ im Ubuntu-Universum nicht mehr. Ersteres könnten die Software-Entwickler einfach sichten und ausbügeln. Zweiteres sei nicht narrensicher. Software sei nicht perfekt und Fehler würden immer gemacht.

Hardlink-Schutz

So genannte Hardlinks ließen sich in ähnlicher Weise für Angriffe ausnutzen, wie das bei den eben genannten symbolischen Links der Fall ist. Allerdings ist das Verhalten hier nicht nur auf Verzeichnisse mit Allerwelts-Rechten beschränkt. Sollten sich zum Beispiel /etc/ und /home/ auf derselben Partition befinden, könnte jeder Anwender einfach einen Hardlink zu /etc/shadow in seinem Home-Verzeichnis erzeugen. Die Datei behält zwar die Original-Rechte, aber Programme mit höheren Privilegien, die normalerweise Symlink-sicher sind, könnten diese Datei durch den Hardlink auslesen. Zusätzlich könnten Bösewichte einen Denial-of-Service-Angriff (DoS) starten, indem sie Verzeichnisse mit Schreibrechten für alle mit Hardlinks fluten und somit den gesamten Plattenplatz in Anspruch nehmen.

Der Ubuntu-Lösungsansatz hier ist, dass Anwender keine Hardlinks zu Dateien erzeugen können, für die sie keine Schreibrechte haben. Auch hier gibt es ähnliche Gegenargumente, wie das bei den Symlinks der Fall ist.