Dieser Abschnitt enthält Informationen zur Datensicherheit im Netzwerk, die beim Zugriff auf entfernte Anwendungen beachtet werden sollten:
Benutzer- und hostspezifische Zugriffskontrollverfahren
MIT-MAGIC-COOKIE-1 und SUN-DES-1 (Zugriffsprotokolle)
Ändern der Server-Zugriffskontrolle
Starten von Anwendungen auf entfernten Systemen (oder lokal) mit einer anderen Benutzerkennung
Die Standard-Zugriffskontrolle von OpenWindows ab Version 3.3 muß nur dann geändert werden, wenn eine der folgenden Bedingungen erfüllt ist:
Sie arbeiten mit einer Anwendung, die mit Xlib- oder libcps-Bibliotheken aus älteren OpenWindows- oder X11-Versionen (älter als Version 2 bzw. X11R4) verknüpft sind.
Sie arbeiten mit einer Anwendung, die statisch mit OpenWindows Version 2 Bibliotheken verknüpft ist, und wollen das Zugriffsprotokoll SUN-DES-1 verwenden.
Sie arbeiten mit einer Anwendung auf einem entfernten Server.
Das Zugriffskontrollverfahren legt fest, welche Clients oder Anwendungen auf den X11/NeWS-Server zugreifen dürfen. Ein Versuch, ohne entsprechende Berechtigung eine Verbindung zum Server herzustellen, wird mit folgender Fehlermeldung beendet.
Xlib: connection to hostname refused by server Xlib: Client is not authorized to connect to server |
Der Verbindungsversuch wird auf der Serverkonsole protokolliert als:
AUDIT: <Datum Zeit Jahr>: X: client 6 rejected from IP 129.144.152.193 port 3485 Auth name: MIT-MAGIC-COOKIE-1 |
Man unterscheidet zwischen benutzerorientierten und hostorientierten Kontrollverfahren. Benutzerspezifische Verfahren regeln den Zugriff auf die Zugangsberechtigungen (Accounts) der Netzwerkbenutzer, während hostspezifische Verfahren die Zugriffsrechte für ein bestimmtes System abfragen. Die benutzerspezifische Zugriffskontrolle kann beim Start von OpenWindows mit der Option -noauth abgeschaltet werden. Weitere Hinweise dazu finden Sie im Abschnitt "D.3.4 Zugriffskontrollverfahren ändern".
Bei einem benutzerorientierten Zugriffskontrollsystem können jedem Netzwerkbenutzer individuelle Zugriffsrechte zugewiesen werden. Greift ein Benutzer auf den Server zu, fragt dieser Autorisierungsdaten ab, die von der Client-Anwendung gesendet werden. Stimmen die Daten mit den auf dem Server gespeicherten Daten überein, erhält der Benutzer Zugang zu dem Server-System.
Bei einem hostorientierten Zugriffskontrollsystem werden Zugriffsrechte nicht an Benutzer, sondern an Hostsysteme vergeben. Da alle Benutzer eines berechtigten Systems auf den Server zugreifen können, bietet dieses Verfahren weniger Schutz vor unberechtigten Zugriffen als benutzerorientierte Verfahren.
Die Solaris-Systemumgebung unterstützt die hostorientierte Zugriffskontrolle, um Abwärtskompatibilität zu gewährleisten. Anwendungen, die mit Xlib- oder libcps-Bibliotheken verknüpft sind, die aus älteren OpenWindows- oder X11-Versionen stammen (älter als Version 2 bzw. Release 4), erkennen das neue benutzerorientierte Kontrollverfahren nicht. Damit auch diese Anwendungen auf den Server zugreifen können, muß der Benutzer entweder auf das hostorientierte Verfahren umschalten oder die Anwendungen mit aktuelleren Bibliotheksversionen verknüpfen.
Aus Sicherheitsgründen sollte, soweit möglich, die zweite Methode verwendet werden.
OpenWindows Version 3.3 unterstützt die Zugriffsprotokolle MIT-MAGIC-COOKIE-1 und SUN-DES-1. Diese Protokolle arbeiten mit unterschiedlichen Autorisierungsdaten, die aber auf ähnliche Weise abgefragt werden. Auf einem Server kann immer nur ein Protokoll implementiert sein. OpenWindows arbeitet standardmäßig mit MIT-MAGIC-COOKIE-1, das ein benutzerorientiertes Kontrollverfahren verwendet.
Das Zugriffsprotokoll MIT-MAGIC-COOKIE-1 wurde am Massachussetts Institute of Technology entwickelt. Beim Start eines Systems über den Server wird für den Benutzer ein sogenanntes Magic Cookie erzeugt und auf dem Server gespeichert. Versucht dieser Benutzer danach, auf den Server zuzugreifen, sendet der Client das Magic Cookie zusammen mit der Verbindungsanforderung. Der Server vergleicht das Magic Cookie mit dem bei ihm gespeicherten Magic Cookie und stellt die Verbindung nur bei einer Übereinstimmung her.
Das von Sun entwickelte Zugriffsprotokoll SUN-DES-1 basiert auf Secure RPC (Remote Procedure Call). Bei diesem Protokoll sendet der Client mit der Verbindungsanforderung den mit DES (Data Encryption Software) verschlüsselten Netzwerknamen des Benutzers. Der Server entschlüsselt den Namen und prüft, ob der Benutzer registriert ist.
SUN-DES-1 bietet einen höheren Zugriffsschutz als MIT-MAGIC-COOKIE-1, da der systemunabhängige Netzwerkname im Gegensatz zum Magic Cookie von anderen Benutzern nicht für den Serverzugriff verwendet werden kann.
Dieses Protokoll ist nur in Bibliotheken von OpenWindows Version 3 und nachfolgenden Umgebungen verfügbar. Anwendungen, die in Umgebungen vor OpenWindows Version 3 mit statischen Bibliotheken erzeugt wurden, darunter insbesondere Xlib, können dieses Zugriffsprotokoll nicht einsetzen.
Wenn Sie anderen Benutzern Zugang zu Ihrem Server verschaffen wollen, können Sie ihre Netzwerknamen in die Zugriffsliste des Servers aufnehmen. Einzelheiten dazu finden Sie im Abschnitt "D.3.4.3 Zugriffsberechtigungen vergeben (SUN-DES-1)".
Beim Start von OpenWindows können Sie über Befehlsoptionen angeben, daß statt MIT-MAGIC-COOKIE-1 das Protokoll SUN_DES-1 verwendet oder überhaupt keine benutzerorientierte Zugriffskontrolle stattfinden soll. Um auf SUN-DES-1 umzuschalten, starten Sie OpenWindows mit folgendem Befehl:
example% openwin -auth sun-des |
Wenn kein benutzerorientiertes Kontrollverfahren verwendet werden soll, geben Sie in der Befehlszeile die Option -noauth an:
example% openwin -noauth |
Mit
der Option -noauth wird der Zugriffsschutz erheblich reduziert.
Da nach der Deaktivierung der benutzerorientierten Zugriffskontrolle nur noch
die Berechtigung des zugreifenden Systems abgefragt wird, kann jeder Benutzer,
der Zugriff auf Ihr System hat, auch auf den Server zugreifen.
Wenn Sie die benutzerorientierte Zugriffskontrolle nicht mit der Option -noauth deaktiviert haben (siehe "D.3.3.3 Standardprotokoll ändern"), sind beide Kontrollverfahren aktiv. Der Server fragt zunächst die Berechtigung des Benutzers und dann die des Systems ab. Bei der Abfrage der Benutzerdaten wird standardmäßig MIT-MAGIC-COOKIE-1 verwendet, während die Systemdaten gegen eine leere Liste geprüft werden, d. h. tatsächlich wirksam ist nur die benutzerorientierte Zugriffskontrolle. Mit der Option -noauth weisen Sie den Server an, dieses Kontrollverfahren abzuschalten und die hostorientierte Zugriffskontrolle durch Aufnahme des lokalen Systems in die Hostliste zu initialisieren.
Das vom Server verwendete Zugriffskontrollverfahren kann über eines der Programme xhost und xauth geändert werden. Weitere Informationen hierzu finden Sie in den man pages. Diese Programme greifen auf zwei Binärdateien zu, die von dem Zugriffsprotokoll erzeugt werden und verbindungsspezifische Autorisierungsdaten enthalten. Die eine Datei wird nur vom Server verwendet, die andere befindet sich im Home-Verzeichnis des Benutzers:
.Xauthority Client-Datei
Mit dem Programm xhost bearbeiten Sie die Hostliste auf dem Server. Sobald Sie einen Hostnamen in die Liste aufnehmen, wird der Zugriffsschutz reduziert, da nun alle Benutzer dieses Systems auf den Server zugreifen können, ohne sich weiter ausweisen zu müssen (siehe "D.3.2.2 Hostorientierte Zugriffskontrolle").
Mit dem Programm xauth greifen Sie auf die Autorisierungsdaten in der Client-Datei .Xauthority zu. Sie können diese Daten beispielsweise einem anderen Benutzer zur Verfügung stellen, der sie dann in seine Client-Datei einträgt, und ihm so den Zugriff auf Ihren Server ermöglichen.
Weitere Hinweise zur Verwendung von xhost und xauth finden Sie im Abschnitt "D.3.4.2 Zugriffsberechtigungen vergeben (MIT-MAGIC-COOKIE-1)".
Die Datei .Xauthority enthält Einträge in folgendem Format:
Verbindungsprotokoll Zugriffsprotokoll Autorisierungsdaten |
Normalerweise ist als Zugriffsprotokoll nur MIT-MAGIC-COOKIE-1 angegeben, und die erste und dritte Spalte enthalten nur Einträge für das lokale System. Auf dem Host anyhost könnte der Inhalt der Datei .Xauthority beispielsweise so aussehen:
anyhost:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75 localhost:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75 anyhost/unix:0 MIT-MAGIC-COOKIE-1 82744f2c4850b03fce7ae47176e75 |
Beim Start des Clients wird der entsprechende Eintrag aus der Datei .Xauthority gelesen, und die Daten aus den Spalten 2 und 3 werden zusammen mit der Verbindungsanforderung an den Server gesendet. In der Standardkonfiguration liefern xhost und newshost leere Host-Zugriffslisten zurück und melden, daß die Zugriffskontrolle aktiviert wurde.
Wenn Sie statt des Standardprotokolls das Protokoll SUN-DES-1 gewählt haben, ist in der Datei .Xauthority in Spalte 2 SUN-DES-1 und in Spalte 3 der Netzwerkname des Benutzers angegeben. Der Netzwerkname erscheint in folgendem Format:
unix.benutzer_id@NISdomain_name |
Auf dem Host anyhost könnte der Inhalt der Datei .Xauthority beispielsweise so aussehen (unix.15339@EBB.Eng.Sun.COM ist der systemunabhängige Netzwerkname des Benutzers):
anyhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM" localhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM" anyhost/unix:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM" |
Wenn Sie Ihren Netzwerknamen nicht kennen, wenden Sie sich bitte an Ihren Systemverwalter.
Wenn Sie das Zugriffsprotokoll MIT-MAGIC-COOKIE-1 verwenden, können Sie einen Benutzer folgendermaßen für den Zugriff auf Ihren Server berechtigen:
Extrahieren Sie auf dem Server mit xauth einen Eintrag im Format hostname:0 in eine Datei.
In diesem Beispiel wird als Hostname anyhost und als Dateiname xauth.info: verwendet:
myhost% /usr/openwin/bin/xauth nextract - anyhost:0 > $HOME/xauth.info |
Senden Sie die Datei (z. B. mit der Anwendung Post" oder dem Programm rcp) an den Benutzer, der zugriffsberechtigt werden soll.
Aus Datenschutzgründen sollten Sie die Datei möglichst per elektronische Post versenden. Wenn Sie rcp verwenden, sollten Sie die Datei nicht in einem Verzeichnis ablegen, auf das von anderen Benutzern leicht zugegriffen werden kann.
Der Empfänger der Datei muß den Eintrag in die Datei .Xauthority in seinem Home-Verzeichnis aufnehmen.
Zum Beispiel:
userhost% /usr/openwin/bin/xauth nmerge - < xauth.info |
Da die Autorisierungsdaten verbindungsspezifisch sind, werden sie bei einem Neustart des Servers ungültig.
Wenn Sie das Zugriffsprotokoll SUN-DES-1 verwenden, können Sie einen Benutzer folgendermaßen für den Zugriff auf Ihren Server berechtigen:
Registrieren Sie den Benutzer mit xhost auf dem Server.
In diesem Beispiel wird Benutzer somebody für das System myhost: zugriffsberechtigt:
myhost% xhost + somebody@ |
Der neue Benutzer muß den Eintrag mit xauth in die Datei .Xauthority in seinem Home-Verzeichnis übernehmen.
In diesem Beispiel lautet der Netzwerkname des neuen Benutzers unix.15339@EBB.Eng.Sun.COM. Bei der Eingabe muß auf das Pipe-Zeichen ein Leerzeichen folgen.
userhost% echo 'add myhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"' | $OPENWINHOME/bin/xauth |
X-Clients rufen den Namen des Servers, zu dem die Verbindung hergestellt werden soll, aus der Umgebungsvariablen DISPLAY ab.
So starten Sie eine Client-Anwendung auf einem entfernten oder unter einem anderen Namen auf dem lokalen System:
Berechtigen Sie einen anderen Benutzer zum Zugriff auf den Server.
Folgen Sie dazu den Anweisungen im Abschnitt "D.3.4.2 Zugriffsberechtigungen vergeben (MIT-MAGIC-COOKIE-1)" oder "D.3.4.3 Zugriffsberechtigungen vergeben (SUN-DES-1)".
Setzen Sie DISPLAY auf den Namen des Hosts, auf dem der Server läuft.
In diesem Beispiel heißt der Host remotehost:
myhost% setenv DISPLAY remotehost:0 |
Starten Sie das Client-Programm.
myhost% client_program& |
Der Client wird auf dem entfernten System (remotehost) angezeigt.