Sicherheit

Aus Sicherheitsgründen werden ein dedizierter Benutzer und eine Gruppenkennung für den ordnungsgemäßen Betrieb empfohlen. Benutzer und Gruppe heißen normalerweise »gdm« auf den meisten Systemen, können aber beliebig benannt werden. Alle grafischen GDM-Benutzeroberflächen werden unter diesem Benutzerkonto gestartet, das heißt alle Programme laufen in der eigenen Umgebung des Benutzerkontos. Das Konto und die Gruppe sollten eingeschränkte Rechte haben.

Das einzige spezielle vom Benutzer »gdm« benötigte Privileg sind Lese- und Schreibrechte für die Xauth-Dateien im Ordner <var>/run/gdm. Der Ordner <var>/run/gdm sollte dem Benutzer root und der Gruppe gdm gehören und die oktalen Zugriffsrechte 1777 haben.

Sie sollte unter keinen Umständen GDM ein Benutzerkonto und eine Gruppenkennung zuweisen, zu denen ein Benutzer leicht Zugang bekommen kann, wie z.B. das Benutzerkonto nobody. Jeder Benutzer, der Zugriff auf einen Xauth-Schlüssel erlangt, kann in der zugehörigen Sitzung eine Benutzeroberfläche belauschen und steuern oder einen Überlastungsangriff auf diese Sitzung starten. Es ist wichtig sicherzustellen, dass das System richtig konfiguriert ist, so dass nur das »gdm«-Benutzerkonto Zugriff auf diese Dateien hat und eine Anmeldung mit diesem Konto nicht einfach möglich ist. Zum Beispiel sollte das Konto nicht ohne Passwort angelegt sein oder eine Anmeldung anderer als Administratoren erlauben.

Die Konfiguration des GDM-Begrüßers wird in GConf gespeichert. Um dem Benutzer »gdm« die Speicherung der Konfiguration zu ermöglichen, benötigt dieser einen schreibbaren persönlichen Ordner ($HOME). Die Benutzer dürfen die vorgegebenen GConf-Einstellungen dahingehend ändern, dass der Benutzer »gdm« auf einen solchen Ordner verzichten kann. Allerdings könnten einige GDM-Funktionen nicht verfügbar sein, falls das Speichern von Statusinformationen in den GConf-Einstellungen nicht möglich ist.

GDM verwendet PAM für die Legitimation beim Anmelden. Die Abkürzung PAM steht für »Pluggable Authentication Module« und wird von den meisten Programmen auf Ihrem Computer verwendet, die eine Legitimation erfordern. Dies ermöglicht dem Systemverwalter, ein spezifisches Anmeldeverhalten für verschiedene Anmeldeprogramme einzustellen, wie beispielsweise SSH, grafische Anmeldung, Bildschirmschoner usw.

PAM ist kompliziert und umfangreich konfigurierbar. Diese Dokumentation beabsichtigt nicht die Konfiguration detailliert zu erklären, es wird jedoch ein Überblick gegeben, wie sich die PAM-Konfiguration auf GDM bezieht, und wie PAM allgemein mit GDM konfiguriert wird. Es wird vorausgesetzt, dass jemand, der PAM konfigurieren will, sich auch weiter in die PAM-Dokumentation vertiefen müsste, um die Konfiguration von PAM und die in diesem Abschnitt verwendeten Begriffe zu verstehen.

Die Konfiguration von PAM hat verschiedene, aber ähnliche Schnittstellen auf unterschiedlichen Betriebssystemen. Lesen Sie die Hilfeseiten zu pam.d und pam.conf für weitere Details. Lesen Sie unbedingt die Dokumentation zu PAM und machen Sie sich mit den Auswirkungen beabsichtigter Konfigurationsänderungen auf die Sicherheit vertraut.

Beachten Sie, dass GDM per Vorgabe den PAM-Dienstnamen »gdm« für die normale Anmeldung und den PAM-Dienstnamen »gdm-autologin« für die automatische Anmeldung verwendet. Diese Dienste dürften nicht in Ihren Konfigurationsdateien »pam.d« oder »pam.conf« definiert sein. Falls dort kein Eintrag existiert, wendet GDM das vorgegebene PAM-Verhalten an. Auf den meisten Systemen funktioniert das recht gut. Allerdings funktioniert die automatische Anmeldung nicht, wenn der Dienst »gdm-autologin« nicht definiert ist.

Das PostLogin-Skript wird ausgeführt, bevor pam_open_session aufgerufen wird, das PreSession-Skript danach. Dies ermöglicht dem Systemverwalter, diverse Skripte zum Anmeldeprozess hinzuzufügen, entweder bevor oder nachdem PAM die Sitzung initialisiert.

Wenn Sie möchten, dass GDM mit anderen Authentifizierungsmechanismen wie Fingerabdruckerkennung oder SmartCard-Lesegeräten zusammenarbeitet, sollten Sie dies als PAM-Servicemodul implementieren, anstatt den GDM-Code direkt zu verändern. Ziehen Sie die PAM-Dokumentation Ihres Systems zu Rate. Von Zeit zu Zeit wird auch in der Mailingliste

PAM hat einige Einschränkungen bezüglich der Fähigkeit, mit mehreren Legitimationsarten gleichzeitig umzugehen, wie die Unterstützung für sowohl die Anmeldung mittels SmartCard als auch über die Eingabe von Benutzername und Passwort im Anmeldeprogramm. Es gibt jedoch Möglichkeiten, dass auch das funktioniert. Am besten ist es, beim Erstellen einer solchen Konfiguration zunächst nach allgemein funktionierenden Lösungen für dieses Problem zu suchen.

Falls die automatische Anmeldungen auf einem System nicht funktioniert, überprüfen Sie, ob der Abschnitt »gdm-autologin« in der Konfiguration von PAM definiert ist. Damit sie funktioniert, ist es erforderlich ein PAM-Modul zu verwenden, das gar keine Legitimierung durchführt, oder das einfach »PAM_SUCCESS« aus allen öffentlichen Schnittstellen zurückgibt. Wenn man davon ausgeht, dass ein System das PAM-Modul »pam_allow.so« installiert hat, welches genau dies tut, so würde eine PAM-Konfiguration zum Einschalten von »gdm-autologin« folgendermaßen aussehen:

       gdm-autologin auth  required    pam_unix_cred.so.1
       gdm-autologin auth  sufficient  pam_allow.so.1
       gdm-autologin account  sufficient  pam_allow.so.1
       gdm-autologin session  sufficient  pam_allow.so.1
       gdm-autologin password  sufficient  pam_allow.so.1

Die obige Konfiguration wird keinen lastlog-Eintrag erzeugen. Falls ein Eintrag gewünscht wird, verwenden Sie die folgende für die Sitzung:

       gdm-autologin session required pam_unix_session.so.1

Wenn der Computer von verschiedenen Benutzern verwendet wird, ist eine automatische Anmeldung nicht sinnvoll, aber vielleicht möchten Sie einigen Benutzern eine Anmeldung ohne Passwort ermöglichen. Dieses Merkmal kann einzeln für jeden Benutzer mit dem Werkzeug »Benutzer und Gruppen« aktiviert werden; es wird durch Zuweisen des Benutzers zur Benutzergruppe »nopasswdlogin« vor Eingabe eines Passwortes erreicht. Damit es funktioniert muss die PAM-Konfigurationsdatei für den Service »gdm« z.B folgende Zeile enthalten:

      gdm auth  sufficient  pam_succeed_if.so  user ingroup nopasswdlogin

GDM erstellt utmp- und wtmp-Einträge in der Benutzerdatenbank bei Anmeldung und Abmeldung von einer Sitzung. Die utmp-Datenbank enthält Informationen zu Benutzerrechten und -konten, auf die solche Befehle wie finger, last, login, und who zugreifen. Die wtmp-Datenbank enthält die Chronik der Benutzerrechte und -konten für die utmp-Datenbank. Schauen Sie für weitere Informationen in die Handbücher von utmp und wtmp.

Die Dateien des XServer zur Legitimierung werden beim Start in einem neu erstellten Unterordner von <var>/run/gdm abgelegt. Die Dateien werden zum Hinterlegen und Austauschen eines »Passworts« zwischen X-Clients und dem XServer verwendet. Dieses »Passwort« ist für jede laufende Sitzung eindeutig, so dass Benutzer aus einer Sitzung nicht die eines anderen Benutzers belauschen können.

GDM unterstützt nur das Legitimierungsschema »MIT-MAGIC-COOKIE-1« des Xserver. Normalerweise ist der Mehrwert anderer Schemata gering. Daher wurden bisher keine Anstrengungen unternommen, sie zu implementieren. Seien Sie beim Einsatz von XDMCP vorsichtig, weil der Xserver Legitimations-Cookie unverschlüsselt gesendet wird. Falls ein Mithören möglich ist, kann ein Angreifer das Legitimationspasswort während der Anmeldung unabhängig vom verwendeten Schema erspähen. Wenn ein Belauschen möglich, aber unerwünscht ist, dann sollte eine X-Verbindung getunnelt werden, anstatt dem XDMCP einzusetzen. Sie können sich XDMCP als eine Art grafisches Telnet mit den gleichen Sicherheitsproblemen vorstellen. In dem meisten Fällen sollte »ssh -Y« dem Leistungsmerkmal XDMCP vorgezogen werden.

Obwohl Ihre Anzeige durch Cookies geschützt wird, werden XEvents und damit auch Tastatureingaben von Passwörtern unverschlüsselt versendet. Sie können sehr leicht belauscht werden.

XDMCP ist vorrangig nützlich zum Betreiben von Thin Clients an Terminal-Servern. Diese Thin Clients benötigen lediglich ein Netzwerk, um auf den Server zugreifen zu können. Daher scheint es die sicherheitstechnisch beste Lösung zu sein, die Thin Clients in einem separaten Netzwerk zu belassen, das keine Verbindung zur Außenwelt hat und sich nur mit dem Server verbinden kann. Der einzige Zugangspunkt nach außen ist der Server. In dieser Art der Konfiguration gibt es keinen unverwalteten Hub oder ein anderes ausspähbares Netzwerk.

Die XDMCP-Zugangskontrolle geschieht mittels TCP-Wrappern. Es ist möglich, GDM ohne Unterstützung für TCP-Wrapper zu konfigurieren, so dass diese Funktion auf manchen Betriebssystemen vielleicht nicht unterstützt wird.

Sie sollten den Dienstnamen gdm in den Dateien <etc>/hosts.allow und <etc>/hosts.deny verwenden. Um zum Beispiel die Anmeldung von Computern aus der Domäne .evil.domain zu verhindern, fügen Sie

gdm: .evil.domain

der Datei <etc>/hosts.deny hinzu. Sie können auch

gdm: .your.domain

der Datei <etc>/hosts.allow hinzufügen, wenn Sie normalerweise alle Dienste von allen Rechnern erlauben. Lesen Sie die Hilfeseiten zu hosts.allow(5) für weitere Informationen.

Obwohl GDM bemüht ist, mögliche Angreifer auf XDMCP auszutricksen, ist es dennoch ratsam, dass der XDMCP-Port (normalerweise UDP Port 177) durch Ihre Firewall geblockt wird, falls Sie es nicht unbedingt benötigen. GDM schützt vor verteilten Überlastungsangriffen, aber das X-Protokoll ist von Natur aus unsicher und sollte nur in sicheren Umgebungen verwendet werden. Ebenfalls werden durch jede entfernte Verbindung viele Systemressourcen belegt, was einen Überlastungsangriff mittels XDMCP leichter macht als gegen einen Webserver.

Es ist ratsam, alle Ports des XServer zu blockieren. Das sind die TCP-Ports 6000+ (einer für jede Anzeige) auf Ihrer Firewall. Bedenken Sie, dass GDM die Anzeigennummern 20 und höhere für die flexiblen Bedarfsserver verwendet.

X ist kein besonders sicheres Protokoll im Netz, und XDMCP ist sogar noch unsicherer.

GDM kann so konfiguriert werden, das PolicyKit verwendet wird. Dies ermöglicht dem Systemverwalter die Entscheidung darüber, ob der Anmeldebildschirm die Knöpfe zum Ausschalten und Neustart des Rechners im Begrüßer anzeigen soll oder nicht.

Diese Knöpfe werden durch die Aktionen org.freedesktop.consolekit.system.stop-multiple-users und org.freedesktop.consolekit.system.restart-multiple-users gesteuert. Die Richtlinie für diese Aktionen kann mit dem Werkzeug »Zugriffsberechtigungen« (polkit-gnome-authorization) oder mit dem Befehlszeilenprogramm »polkit-auth« festgelegt werden.

GDM kann so konfiguriert werden, dass RBAC anstelle von PolicyKit verwendet wird. In diesem Fall wird die RBAC-Konfiguration verwendet, um festzulegen, ob im Begrüßungsbildschirm die Knöpfe für Herunterfahren und Neustart angezeigt werden.

Zum Beispiel wird bei Oracle Solaris die Legitimation »solaris.system.shutdown« zum Steuern verwendet. Ändern Sie einfach die Datei /etc/user_attr so, dass der Benutzer »gdm« diese Legitimation hat.