Login
Newsletter
Werbung

Mo, 1. Dezember 2003, 00:00

GNU/Hurd Security

In diesem Artikel soll beschrieben werden, inwiefern sich das Sicherheitskonzept des Hurd von dem unter Unix üblichen unterscheidet und was damit erreicht werden soll.

Unter Unix-artigen Systemen kann ein Prozess seine Rechte nur vermindern, nicht erhöhen. Auf den ersten Blick erweckt das den Eindruck, dass hierdurch Sicherheit erreicht würde. In der Praxis ist das Gegenteil der Fall. Ein typischer FTP-Daemon läuft unter Unix zunächst als root, um Port 21 belegen zu können. Erst wenn ein Benutzer sich mit einem gültigen Benutzernamen und dem zugehörigen Passwort authentifiziert hat, gibt der Daemon die root-Rechte ab und läuft mit den Rechten des betreffenden Benutzers. Das bedeutet, dass der Daemon mit einem vollkommen Fremden kommuniziert, während er über root-Rechte verfügt. Es ist nicht sehr viel Fantasie notwendig, um zu bemerken, dass dies eine sehr große potentielle Gefahr ist. Auch in der Praxis war dies die Ursache für einige ernsthafte Sicherheitsprobleme.

Im GNU/Hurd Betriebssystem gibt es einen Mechanismus, der diese Gefahr stark vermindert. Während ein Benutzer unter Unix zwar über mehrere Group-IDs verfügen kann, bietet Hurd die Möglichkeit, einen Prozess auch mit mehreren User-IDs auszustatten - oder eben auch gar keiner. Das bedeutet, dass ein FTP-Daemon alle seine Rechte abgeben würde, nachdem er den Port belegt hat. Aus Kompatibilität zu Unix (genauer: POSIX) wird zwar noch eine User-ID angegeben, nämlich "-1", doch praktisch läuft der Prozess nun ohne UID, d.h. er verfügt auch nicht über die Berechtigungen, die im rwx-Trio einer Datei für alle Benutzer des Systems gelten, die nicht Besitzer der Datei sind und nicht zur betreffenden Gruppe gehören. Wenn sich ein Benutzer nun beim FTP-Daemon anmeldet, wird dieser das angegebene Benutzername/Passwort-Paar an den "password"-Serverprozess schicken (der über /servers/password angesprochen werden kann), der ein entsprechendes Authentifikationstoken als Antwort liefert.

Für Prozesse ohne UID gibt es im Dateisystem des GNU/Hurd Systems ein speziell dafür vorgesehenes viertes rwx-Trio, über das man auch solchen Prozessen vereinzelt gewisse Möglichkeiten bieten kann, wenn man das möchte. Leider zeigen Programme wie ls dies derzeit noch nicht an; Unterstützung dafür hinzuzufügen wäre eine interessante Aufgabe für Leute, die in die Hurd-Entwicklung einsteigen möchten.

Die Flexibilität von Hurd birgt aber auch einen kleinen Nachteil: Auch nach einem chroot()-Aufruf ist es theoretisch möglich, wieder Zugriff auf das echte Root-Dateisystem zu erhalten. Ein Knoten im Dateisystem wird durch einen Port repräsentiert und es ist möglich, einen Port in einer Message an einen anderen Prozess zu schicken. Um dies ausnutzen zu können, wäre sowohl ein Prozess notwendig, der Zugriff auf den /-Port hat und den betreffenden Port dem anderen Prozess sendet, als auch ein Prozess innerhalb der chroot()-Umgebung, der diesen entgegennimmt und verwendet. Doch die theoretische Möglichkeit besteht.

Immer wieder wird gefragt, ob GNU/Hurd über ACLs (Access Control Lists) verfügt. Derzeit ist dies nicht der Fall. Dazu gibt es wohl zwei wichtige Gründe. Der erste ist sehr einfach: Es hat sich bisher noch niemand so sehr dafür interessiert, dass er es implementiert hätte. Das bedeutet aber keinesfalls, dass ACLs grundsätzlich unerwünscht wären. Der zweite Grund ist weniger gewichtig, aber dennoch ein nicht von der Hand zu weisendes Problem: Es gibt noch keinen Standard in der Unix-Welt, der die Handhabung von ACLs definiert. Es wäre wünschenswert, direkt einen Standard implementieren zu können, statt zunächst eine eigene Lösung zu erstellen, um später Teile der erledigten Arbeit zu wiederholen, um einen dann existierenden Standard zu unterstützen.

Zuletzt ist wohl noch ein Hinweis auf die sogenannte Login-Shell nötig. Dies ist eine gewöhnliche Shell, die ohne User-ID läuft und jedem auch vor dem Login zur Verfügung steht. Selbstverständlich ist es ein Sicherheitsrisiko, diese Shell nicht zu deaktivieren. Es ist problemlos möglich, diese Shell durch das gewohnte Login-Programm zu ersetzen (und für den produktiven Einsatz in vielen Bereichen sicherlich auch ratsam), doch zumindest derzeit ist die Voreinstellung ein System, dass jeden dazu ermutigen soll, es kennenzulernen. Leider ist es nicht möglich, gleichzeitig so einladend wie ITS zu sein und so sicher wie Unix (bzw. sicherer), daher bietet GNU/Hurd die Wahl.

Kommentare (Insgesamt: 0 )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung