Netzwerktransparenz

Sicherheitsaspekte von X11

X11 ist ohne geeignete Absicherungsmaßnahmen kein sicheres Protokoll. Ein völlig offener X-Server läßt jeden im Netzwerk z.B. den Inhalt seiner Fenster mitlesen - unbemerkt vom Anwender, der davor sitzt. Dazu ist es nicht einmal erforderlich, im Netzwerk zu "sniffern", vielmehr handelt es sich um X11-Standardfunktionalität, realisiert mit einfachen X-Tools. xwd und xgrabsc sind zwei ganz simple Beispiele.

Die normale X11-Distribution unterstützt zwei Sicherheitsmechanismen: das schwächere xhost-Verfahren, das den Zugriff pro Maschine regelt, und das stärkere xauth, das den Zugriff pro User regelt.

Host Access Control List

Um das Gröbste zu verhindern, erlaubt xhost nur X-Clients von bestimmten Hosts, den X-Server anzusprechen:

xhost +remote-rechner

fügt remote-rechner zur Liste der berechtigten Hosts.

xhost

ohne weiter Parameter gibt die Liste der berechtigten Hosts aus. Von anderen Maschinen gelingt dann das einfache Sceen-Grabben nicht mehr, der Zugriff auf den X-Server von Hosts, die nicht in dieser "Access Control List" stehen, wird verweigert.

xhost -remote-rechner

entfernt remoter-rechner aus der Liste.
Vorsicht: xhost + ohne Angabe eines Host schaltet die Zugangskontrolle einfach ab, xhost - schaltet sie wieder an.
Problem: Weiterhin kann jeder User auf einer der berechtigten Maschinen auf den X-Server zugreifen und unbemerkt mitlesen - nicht unbedingt erwünscht.

Xauth-Zugriffssteuerung

Abhilfe schafft hier das differenziertere, aber deutlich aufwändigere xauth-Verfahren. Kern des Verfahrens ist eine kryptische Zeichenfolge, ein sog. "MAGIC- COOKIE", das nur dem berechtigten User und dem X-Server bekannt ist. Damit läßt sich der Zugang zum X-Server genau auf einen oder bestimmte User beschränken.
Linux-User müssen sich hier kaum Sorgen machen: Sowohl die gängigen Display-Manager (xdm, kdm, gdm) als auch das Skript startx sichern die X-Session automatisch mit xauth ab. Das verwendete Cookie wird dazu in $HOME/.Xauthority geschrieben. Hier zur Illustration der Abschnitt im startx-Skript, wo ein neues Cookie erzeugt wird:

# set up default Xauth info for this machine
mcookie=`mcookie`
if [ X"$XAUTHORITY" = X ]; then
    authfile="$HOME/.Xauthority"
else
    authfile="$XAUTHORITY"
fi
serverargs="$serverargs -auth $authfile"
xauth -f $authfile source - <<-EOF
        add $display . $mcookie
        add `hostname -f`$display . $mcookie
        add `hostname -f`/unix$display . $mcookie
EOF
mcookie=

Anschließend wird der X-Server u.a. mit der Option -auth $authfile gestartet (Das erledigt ebenfalls das startx-Skript).

Xhost überschreibt Xauth

Was passiert bei Anwendung beider Zugriffskontrollverfahren? Der X-Server läßt jeden zu, der durch einen der beiden Mechanismen Zugriff hat - er muss also nicht beide Kontrollen passieren, es genügt eine. Das kommt vielleicht etwas überraschend; letzlich läuft das darauf hinaus, dass xhost das striktere xauth schnell aushebelt. Wenn xauth verwendet wird, sollte der Zugriff überxhost komplett abgeschaltet sein.
Unter Linux ist das die Standard-Einstellung, komplizierter ist die Situation von Windows zu Linux.

Echte Sicherheit bringen diese beiden Verfahren allerdings nicht. In jedem Fall läuft die X11-Kommunikation gänzlich unverschlüsselt über das Netzwerk und ist somit schutzlos gegen intelligente Sniffer-Tools. Besondere Schwachstelle ist die unverschlüsselte Authentifizierung an der UNIX-Seite, egal, ob das über TELNET, REXEC oder XDMCP geschiet.
Abhilfe schafft hier der Einsatz der Secure Shell (kurz SSH), die Gegenstand des nächsten Kapitels ist.