Technische Praxis der Computersysteme Teil 1 - Universität Wien

7 X-WINDOW
Eine große Stärke des X-Window-Systems beruht auf seiner Client/Server-Architektur.
Das X-Window-System ist ”
von Haus aus“ netzwerkfähig und es ist sehr einfach, Programme
remote auszuführen, d.h. X-Clients nicht am lokalen Rechner laufen zu lassen, sondern die
Fenster über ein Netzwerk an den X-Server am lokalen Rechner zu ”
schicken“. Das ist vor
allem dann von großem Vorteil, wenn ein starker Rechner (Applikationsserver, auf dem die
X-Clients laufen) im LAN vorhanden ist, währen die Arbeitsplatzrechner (Workstation, auf
ihr läuft der X-Server) nur über schwächere Hardware verfügen.
Nachdem X-Clients grossen Einfluss auf das Verhalten des Gesamstsystems ausüben
können, liegt es auf der Hand, daß sich die Clients beim Server als zugriffsberechtigt ausweisen
können müssen. X sieht für diese Authentifizierung mehrere Möglichkeiten vor. Die beiden
gebräuchlichsten sind die hostbasierte Authentifizierung mittels xhost und die benutzerbasierte
Authentifizierung mittels xauth, daß Zugriffsschlüssel (meist MIT-MAGIC-COOKIE-1)
in der Datei .Xauthority verwaltet.
Wir stellen hier zunächst die hostbasierte Authentifizierung mittels xhost dar. Eine
kleine Vorbemerkung: die Verbindung ist auf jeden Fall unverschlüsselt, und die Authentifizierung
erfolgt auf Basis der IP-Adresse! Damit ist diese Authentifizierung von Haus aus
so unsicher, daß man sie eigentlich nur in ”
sicheren“ LANs anwenden sollte. Konkret geht
man wie folgt vor.
1. Zuerst muß man dem X-Server mitteilen, daß er X-Client-Verbindungen von anderen
Rechnern (also X-Clients, die auf anderen Systemen laufen) entgegennehmen darf. Dazu
dient das Kommando xhost (Syntax: xhost [+|-] [hostname]). Damit kann man
entweder gezielt einzelnen Rechnern den Zugriff auf den lokalen X-Server ermöglichen
oder verbieten oder gleich generell allen erlauben (nicht empfohlen!) oder untersagen,
X-Fenster an den X-Server zu ”
schicken“ (xhost [+|-]).
2. Am Remote-System, wo die Applikation (der X-Client) laufen soll, muß angegeben
werden auf welchem Display (X-Server) das Fenster erscheinen soll. Dafür gibt es
die Shell-Variable DISPLAY, die man—nach dem Einloggen (etwa über Telnet) am
Applikationsserver—auf den Hostnamen (oder die IP) des Rechners mit dem X-
Server setzt (z.B. export DISPLAY=xserver:0.0, letzteres gibt die Screen- und X-
Servernummer an). Nun kann man X-Programme (wie etwa xeyes, xterm, \dots)
am Applikationsserver ausführen, die Ausgabe erfolgt jedoch am lokalen X-Server. Dies
hat den Vorteil, daß man z.B. für umfangreiche Berechnungen mathematica am Server
rechnen läßt, sich die Ergebnisse aber am langsameren Arbeitsplatzrechner anzeigen
lassen kann.
Will man nur für einzelne X-Programme die Ausgabe umleiten, kann man
das dem Programm auch direkt durch die Option -display mitteilen (z.B.
xterm -display xserver:0.0)
Wir haben schon oben bemerkt, daß X-Verbindungen unverschlüsselt und unsicher sind.
Es stellt für einen Angreifer (eigentlich) überhaupt kein Problem dar, eine X-Verbindung zu
übernehmen (Session-Hijacking), zu missbrauchen oder zu korrumpieren. Es ist deswegen
sicherer, X nur über eine verschlüsselte Verbindung zu verwenden. Die Secure Shell ssh
kann selbständig die Aufgabe des X11-Forwardings übernehmen (mit Hilfe der Option -X,
sodaß das Einloggen per ssh -X user@host ausreicht, um sich X-Clients schicken lassen
zu können. ssh beherrscht auch die benutzerbasierte Authentifizierung (aber nur die mittels
MIT-MAGIC-COOKIE-1). Das ganze funktioniert so, daß der ssh-Server einen Dummy-X-
Server am Zielhost einrichtet, und die entsprechenden Umgebungsvariablen setzt. Er vergibt
auch einen Zugriffsschlüssel (allerdings nicht denselben, der auf dem X-Server-Host verwendet
wird; der vom ssh-Server vergebene Schüssel ist nach Ende der ssh-Session wertlos, der
Originalschlüssel bleibt immer am ssh-Client-Host).
103