Wie funktioniert die x11-Autorisierung? (MIT Magic Cookie)

Question

Ich bin an einer eingehenden Antwort interessiert, die erklärt, wie genau x11 Autorisierung funktioniert und vor allem MIT Magic Cookies.

Ich verstehe, dass es tatsächlich den Zugriff auf alle anderen außer dem angemeldeten Benutzer verbietet, außerdem gibt es einige Kontrollmechanismen, die steuern, ob eine Client-Anwendung eine Verbindung zu einem Xdisplay-Server herstellen kann oder nicht.

Ich fand auch, dass es fünf Standard-Zugriffssteuerungsmechanismen sind, und sie können in drei Hauptkategorien eingeteilt werden:

. Zugriff basierend auf Host

. Zugriff basierend auf Cookie

. Zugriff basierend auf Benutzer

Aber von diesem Punkt an verstehe ich nicht wirklich die Art und Weise, wie diese arbeiten und welche Möglichkeiten sie genau verwenden, um die Berechtigungen zu tun.

Answer 1

Nun, zuerst gibt es eine Datei ~/.Xauthority auf dem Rechner. Beachten Sie, dass (in der Regel auf der Maschine mit GUI) falsche Berechtigungen dieser Datei, kann eine Login-Bildschirm-Schleife verursachen ... (dauerte mir Stunden, um das zu verstehen).

Wie Sie erwähnt sind 5 Mechanismen:

1. Host-Zugriff: Der Server Host-Zugriffsliste hat (wenn eine Netzwerkadresse in dieser Liste vorhanden ist, wird die Verbindung zugelassen). Die Liste wird mit dem Befehl xhost verwaltet. HINWEIS: Dies erlaubt nicht mehr als eine einzelne Verbindung gleichzeitig. Ich weiß nicht mehr über diese Methode, weil ich sie nicht wirklich benutze. Sie können jedoch man Xserver GEWAEHRUNG ACCESS-Bereich :)

2. MIT-magic-Cookie-1 sehen: Erstellen 128bit Schlüssel ("Cookie"), ist es in ~/.Xauthority Speichern (oder wo XAUTHORITY envvar Punkte). Der Client sendet es an den Server plain! Der Server prüft, ob es eine Kopie dieses "Cookies" hat und wenn dies der Fall ist, ist die Verbindung erlaubt. Der Schlüssel wird von DMX generiert.

3. XDM-Autorisierung-1: Auch hier ist ein Schlüssel in ~/.Xauthority gespeichert. Dieser Schlüssel besteht aus 2 Teilen - 56 Bit DES-Verschlüsselungsschlüssel und 64 Bit Zufallsdaten, die als Authentifikator verwendet werden. Wenn Sie eine Verbindung zum Server herstellen, generiert der Client 192bits Daten: ctime kombiniert mit 48Bit Identifier (für tcp/ip: IP Adresse + Port, für lokale Verbindungen ist es die PID und 32 Bit eindeutige ID). Der DES-Schlüssel wird verwendet, um die Daten zu verschlüsseln und dann an den Server zu senden. Der Server validiert den Benutzer, indem er ihn entschlüsselt und dann den 64-Bit-Authentifikator und zusätzliche Daten validiert.

4. sun-des-1: Es verwendet asymmetrische Verschlüsselung, der Server verfügt über einen öffentlichen Schlüssel, den er verwendet, um eingehende Anfragen zu entschlüsseln. Es verwendet auch die "Host-Liste". Dies erfordert einige zusätzliche Mechanismen im Netzwerk, ich habe kein solches Netzwerk so wieder, ich verstehe diesen Mechanismus nicht gut.

5. Server interpretiert: Es kann auf so viele Arten implementiert werden ... aber im Allgemeinen sendet der Client 2 Zeichenfolge an den Server. Die zweite Zeichenfolge ist der Benutzereintrag (z. B. Benutzername) und die erste Zeichenfolge ist der Eintragstyp (z. B. localuser).

HINWEIS: die 2., 3. und 4. Mechanismen speichern die Schlüssel in ~/.Xauthority daher jeder, der Zugriff auf diese Datei hat, kann mit dem Server verbinden vorgibt, „Sie“ zu sein.

xauth-Befehl kann Xauthority-Datei analysieren und die interessanten Werte extrahieren.

$ xauth 
Using authority file /home/ME/.Xauthority 
xauth> list   
ME/unix:10 MIT-MAGIC-COOKIE-1 5e443c146376d0bdadfd712bfe7654be 
ME/unix:0 MIT-MAGIC-COOKIE-1 c48ddba801384dce3aaaa9d442931ea12 
xauth> info 
Authority file:  /home/ME/.Xauthority 
File new:    no 
File locked:   no 
Number of entries: 2 
Changes honored:  yes 
Changes made:   no 
Current input:  (stdin):2 
xauth> 

• Die Daten geändert werden ....