Nicht oft, aber doch hin und wieder bekommen wir Hinweise bzw. Anfragen von Usern, die sich darüber wundern (oder sich auch daran stören), dass man bei uns sehen kann, welche User es so auf einem System gibt. Manche finden das unschön; andere sehen uns in diesem Punkt als „tiefenentspannt“, manche sehen darin auch eine schwere Sicherheitslücke - die es aber faktisch gar nicht ist.

Die kurze Antwort ist: „Das ist bei Unix eben so“.

Die lange Antwort:

Letztlich betrifft die Fragestellung nicht nur den Inhalt von /home. Sie betrifft beispielsweise genauso auch die /etc/passwd, in der ebenfalls sämtliche User aufgeführt sind. Bis zum Jahr 1992 waren selbst die Passwörter der User (natürlich nur als crypt-Hash, nicht im Klartext) in der /etc/passwd gespeichert, bis dann die Shadow Password Suite in jenem Jahr auf Linux portiert wurde, die vereinfacht gesagt eine /etc/shadow eingeführt hat, in der die gehashten Passwörter ausgelagert wurden und jene Datei dann nur für root lesbar war, während die Liste der User weiterhin in der /etc/passwd einsehbar blieb und bis heute ist.

Dieses Prinzip ist durch die Bank weg bei praktisch allen heutigen Linux-Distributionen immer noch so. Jeder Ansatz, der dies verhindern wollte, müsste daher nicht nur das Auflisten des Inhalts von /home unterbinden (was relativ einfach mit einem chmod -r /home machbar wäre), sondern auch dafür sorgen, dass auch die /etc/passwd nicht mehr lesbar ist. Das ist, ganz simpel gesagt, nicht so trivial machbar. Der gängige Weg, wie man hiermit umgehen könnte, wäre, alle User in eine sogenannte chroot-Umgebung einzusperren, das heißt, man erklärt ihr Home-Verzeichnis gewissermaßen als ihre „oberste Verzeichnisebene“. Das bedeutet aber auch, dass die User nicht mehr auf Programme zugreifen können, die außerhalb ihres Home-Verzeichnisses liegen - man müsste ergo Kopien bzw. Hardlinks allerProgramme in jedes Home-Verzeichnis packen, damit die User auch weiterhin eine Shell haben, Befehle ausführen können, Programmiersprachen nutzen können. Das kann man machen, sicher. Es ist aber nicht wirklich praktikabel und trägt aus unserer Sicht auch nicht nennenswert dazu bei, die Sicherheit zu erhöhen. Noch dazu würde es andere Teile unseres Sicherheitskonzepts sogar torpedieren, beispielsweise den Fakt, dass wir dem Webserver grundsätzlich keinen Zugriff auf /home/$USERgeben, sondern forcieren, dass alle Inhalte, die ins Web kommen dürfen, außerhalb unter der Struktur /var/www/virtual/$USER abgelegt werden müssen, damit der Webserver unter keinen Umständen Zugriff auf andere Inhalte im Home-Verzeichnis bekommt, beispielsweise auf Konfigurationsdateien, oder viel wichtiger noch, auf dort abgelegte Mails.

Letztlich müsste man das Spiel sehr weit treiben. Man müsste nämlich auch dafür sorgen, dass auch sämtliche Scripts, die vom Webserver aus gestartet werden, egal in welcher Programmiersprache, ebenfalls in jene chroot-Umgebung gepackt werden - ansonsten wäre jene reine Augenwischerei, weil man eben auf anderem Weg sehr wohl immer noch auf das restliche System zugreifen könnte.

Wir haben schon viele Accounts bei vielen anderen Providern ausprobiert. Die „Sicherheit“, die dort in dieser Hinsicht geboten wurde, war durch die Bank weg löchrig wie ein Schweizer Käse (womit wir nicht zum Ausdruck bringen wollen, dass jene anderen Provider unsicher wären; wir sehen in dem Umstand der einsehbaren Userliste ja eben gerade kein Sicherheitsproblem, weder bei uns noch anderswo). Die einen haben beispielsweise mit open_basedir in der php.ini gearbeitet, was aber erstens nur auf PHP wirkt und auf keine andere Programmiersprache, und was zweitens auch nicht auf Befehle wirkt, die aus PHP heraus mittels system() ausgeführt werden (aber klar, das kann man natürlich auch sperren). Ein anderer Provider hat kurzerhand dem Befehl ls die Ausführungsrechte genommen, was einerseits total lächerlich ist, weil es gefühlte tausend Möglichkeiten gibt, einen Verzeichnisinhalt auch ohne ls aufzulisten, und andererseits eine gewöhnliche SSH-Shell unbenutzbar macht. Wieder ein anderer hat /home die r-Rechte genommen, womit man zwar noch hineinwechseln kann, aber sich keine Liste des Inhalts mehr erstellen kann. Beim gleichen Provider war die /etc/passwd wiederum lesbar. Häufig werden User beim FTP-Zugriff eingesperrt (weil viele FTP-Server hierfür triviale Möglichkeiten bieten, ohne eine echte chroot-Umgebung aufzusetzen), aber lädt man darüber dann ein CGI-Script hoch - unterliegt das in seiner Ausführung dann häufig wiederum keinen Beschränkungen. Die Liste nimmt kein Ende. Unter einem halben Dutzend Accounts bei verschiedensten Providern haben wir keinen gefunden, bei dem es nicht auf die eine oder andere Weise möglich war, an eine Liste von Benutzern auf dem System zu gelangen. Nur vielleicht eben nicht auf den ersten Blick.

Wir halten nun zugegebenermaßen nicht sehr viel davon, Dinge einfach nur irgendwie zu „erschweren“, die hintenrum dann weiterhin genauso offen sind wie vorher. Entweder, man unternimmt einen wirkungsvollen Schritt, oder man sollte sein Sicherheitskonzept überdenken - ich brauche kein Sicherheitsschloss an meiner Haustür, wenn ich hinten die Balkontür offen stehen lasse. Damit hielte man nicht ernsthaft Einbrecher ab, sonden maximal vorwitzige Spaziergänger, die einfach mal neugierig vorne an der Haustür an den Klinken rütteln. Wir haben daher einen viel stärkeren Fokus darauf gelegt, konsequent in allen Teilen des Systems zu forcieren, dass alle Dinge, die User ausführen können, zwingend auch mit deren Rechten und damit auch genau mit deren Einschränkungen laufen - nicht nur auf der Shell, sondern eben beispielsweise auch bei der Mailzustellung (der Delivery-Prozess läuft im Userspace der jeweiligen User) und insbesondere bei der Ausführung aktiver Inhalte durch den Webserver. Auf diese Weise wird dann nämlich auch forciert, was sie nicht dürfen - nämlich in die Verzeichnisse anderer User eindringen, weder lesend noch schreibend. Also, nur mal um das deutlich zu machen:

[myself@neon ~]$ cd /home/other -bash: cd: /home/other: Permission denied [myself@neon ~]$ cd /var/www/virtual/other -bash: cd: /var/www/virtual/other: Permission denied

Wir sehen absolut kein Sicherheitsproblem darin, nicht zu verschleiern, dass es einen User namens other gibt. Wir sehen auch kein Sicherheitsproblem darin, durch eine Straße zu gehen und zu sehen, dass dort Häuser stehen, an denen sich sogar Klingelschilder mit Namen drauf befinden - das macht diese Häuser nicht automatisch zu Einbruchsopfern. Um bei dem Bild zu bleiben: Wir sorgen dafür, dass jedes Haus vorne und hinten vernünftig abgeschlossen ist. Wir verwenden jedoch keine Mühe darauf, vor die Häuser „Hier ist kein Haus“-Schilder zu stellen und dir zu suggerieren, die ganze Straße bestünde nur aus deinem Haus. Du weißt sowieso, dass das nicht so ist. Korrekte Rechtevergabe verhindert Übergriffe von einem Uberspace auf einen anderen - verstecken verhindert gar nichts. Security by obscurity? We don’t subscribe.

Worauf wir im Gegensatz dazu sehr detailliert geachtet haben, ist, dass nicht einsehbar ist, welche Domains auf einem Uberspace-Host liegen, weil das deutlich tiefer in die Privatsphäre der einzelnen User eingreift als das Wissen um nackte Usernamen (die wir zudem auch auf 8 Zeichen limitieren, was zusätzlich dazu beiträgt, dass diese nicht allzu „sprechend“ sind). Entsprechende Konfigurationsdateien sind also schlicht nicht einsehbar:

[myself@neon ~]$ ls -l /etc/httpd/conf.d ls: /etc/httpd/conf.d: Permission denied [myself@neon ~]$ cat /var/qmail/control/virtualdomains cat: /var/qmail/control/virtualdomains: Permission denied

Wer jetzt trotzdem noch schlaflose Nächte deswegen hat, kann uns gerne kontaktieren. Wir stehen wie üblich gerne Rede und Antwort.

• ← Previous Post
• Next Post →