Verder Terug Inhoud

6. De server vertellen

De server zal niet zomaar een connectie van iedereen accepteren. Je wilt toch niet dat iedereen zo maar een window op je scherm kan zetten. Of lezen wat je schrijft -- onthoud je keyboard is onderdeel van het display!

Veel mensen schijnen zich niet te realiseren dat het toestaan van toegang tot je display een groot security risico is. Iemand met toegang to je display kan lezen van en schrijven naar je scherm, alles lezen wat je typt, en je muis acties registreren.

De meeste servers kennen twee manieren voor het legaliseren van connecties naar de server: het host lijst mechanisme (xhost) en het magic cookie mechanisme (xauth). Dan is er ook nog ssh, de secure shell, die kan X connecties ook doorsturen.

6.1 Xhost

Xhost laat connecties toe op hostnaam. De server houd een lijst bij van host die mogen connecten. Het kan ook host checking volledig uitschakelen. Onthoud: dat betekend dat er geen checks meer uitgevoerd worden, dus iedere host mag connecten!

Je kan de servers host list bijhouden met het programmatje xhost. Om dit te gebruiken moet je het mechanisme uit het volgende voorbeeld gebruiken.

light$ xhost +dark.matt.er

Dit staat connecties van de host dark.matt.er toe. Zodra je X client een connectie heeft gemaakt en een window weergeeft, schakel voor de veiligheid meer connecties uit met:

light$ xhost -dark.matt.er

Je kan host verificatie uitschakelen met:

light$ xhost +

Dit schakelt de host toegang verificatie uit en dus iedereen mag connecten. Je moet dit nooit doen op een netwerk waar je niet alle gebruikers vertrouwd (internet bijvoorbeeld). Je kunt host verificatie weer aanzetten met:

light$ xhost -

xhost - verwijderd niet alle host-Namen uit zichzelf van de toeganslijst (dat zou niet echt slim zijn - je kan dan niet meer connecten naar je Xserver van waar dan ook - zelfs niet vanaf localhost).

Xhost is een zeer onveilig mechanisme. Het maakt geen onderscheid tussen verschillende gebruikers op de remote host. Ook host-Namen (eigenlijk adressen) kunnen gespoofd worden. Dit is vervelend als je op een onbetrouwbaar netwerk zit (internet bijvoorbeeld).

6.2 Xauth

Xauth staat connectie toe aan iedereen die het juiste geheim weet. Zo'n geheim wordt authorization record genoemd, of magic cookie. Dit legalisatie schema is formeel genoemd MIT-MAGIC-COOKIE-1.

De cookies voor verschillende displays staan samen is ~/.Xauthority. Jouw ~/.Xaurthority moet niet toegangkelijk zijn voor andere groepen en gebruikers. Het xauth programmatje houd deze cookies bij, vandaar de bijnaam xauth voor het schema.

Bij het starten van een sessie, leest de server de cookie uit het bestand die aangegeven wordt door de optie -auth. Nadat, de server alleen connecties vanaf clients toelaat met de zelfde cookie. Als de cookie in ~/.Xauthority veranderd, de server zal de verandering dan niet doorvoeren.

Nieuwere servers genereren cookies gelijk als clients er om vragen. Cookies blijven nog steeds behouden binnenin de server; ze komen niet terecht in ~/.Xauthority behalve als een client ze daar zet. Volgens David Wiggins:

Een volgende plooi is toegevoegd aan X11R6.3 daar zou je in geïnteresseerd kunnen zijn. Via het nieuwe SECURITY extensie, kan de X server zelf nieuwe cookies genereren en terugplaatsen ad-hoc. Verder, de cookies kunnen on vertrouwd worden aan gesteld daarom worden applicaties met zulke cookies beperkt in hun handeling. Bijvoorbeeld, ze kunnen dan niet de invoer van muis en keyboard lezen, of de inhoud van windows, van andere vertrouwde gebruikers. Er is een nieuw sub commando gemaakt voor xauth om dit mogelijk te maken voor gebruik.

Xauth heeft is duidelijk veiliger dan xhost. Je kan beperkte toegang voor bepaalde gebruikers en hosts instellen. Het struikelt niet over gespoofde adressen zoals xhost. En als je wilt kun je xhost er ook nog bij gebruiken.

De Cookie maken

Als je xauth wilt gebruiken, moet je de X server starten met de optie -auth authfile. Als je het startx script gebruikt, dan is dat goede plaats om het te doen. Maak een authorization record net als hieronder in je startx script.

Stukje uit /usr/X11R6/bin/startx:

mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

Mcookie is een heel klein programmatje in het util-linux pakkage, hoofd site ftp://ftp.math.uio.no/pub/linux/. Als alternatief kun je ook md5sum gebruiken om verschillende data (van, bijvoorbeeld /dev/urandom of ps -axl) in cookie om te zetten:

dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

Als je het startx script niet kunt aanpassen (omdat je geen root bent) ga dan naar je systeem administrator en vraag hem om dit te doen, of laat hem xdm starten. Als hij het niet kan of wil, dan maak je een ~/.xserverrc script. Als je het script hebt, zal xinit het runnen ipv de echte X server. Dan kun je de echte X server starten vanuit het script met de goed opties natuurlijk. Om dat te doen, laat je ~/.xserverrc de magic cookie regel gebruiken en dan de echte X server starten:

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

Als je xdm gebruikt om je X sessie bij te houden, kun je xauth gemakkelijk gebruiken. Zet het regeltje 'DisplayManager.authDir in /etc/X11/xdm/xdm-config. Xdm zal nu de optie -auth gebruiken als de server start. Als je inlogd bent met xdm, dan zet xdm de cookie in ~/.Xauthority voor je. Zie xdm(1) voor meer informatie. Bijvoorbeeld, mijn /etc/X11/xdm/xdm-config heeft de volgend regel:

Display Manager.authDir: /var/lib/xdm

De cookie transporteren

Als je de X server gestart hebt op de server host light.uni.verse en je hebt je cookie in ~/.Xauthority, dan moet je de cookie transporteren naar de client dark.matt.er.

Het makkelijkst is als je home dir op light en dark zijn gedeeld. De ~/.Xauthority files zijn het zelfde, dus de cookie wordt gelijk getransporteerd. Maar, er zit een addertje onder het gras: als je een cookie voor :0 in de file zet dan denkt dark dat het voor zichzelf is ipv voor light. Dus je moet de volledige host-naam gebruiken als je de cookie maakt; Je kunt het niet weg laten. Je kunt dezelfde cookie installeren voor :0 en light:0 met:

#!/bin/sh
cookie=`mcookie`
xauth add :0 . $cookie
xauth add "$HOST:0" . $cookie
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

Als de homedirectory's niet zijn gedeeld, kun je de cookie transporteren door middel van rsh, de remote shell:

light$ xauth list "${HOST}:0" | rsh dark.matt.er xauth nmerge -

  1. Haal de cookie uit je locale ~/.Xauthority (xauth nlist :0).
  2. Verplaats het naar dark.matt.er (| rsh dark.matt.er).
  3. Zet het in ~/.Xauthority daar (xauth nmerge -).

Notitie voor het gebruik van ${HOST}. Je moet de cookie transporteren die samenhangt met local host. Een remote X applicatie zal het display value :0 gebruiken op de remote machine, dat is niet wat je wilde!

Het is mogelijk dat rsh niet voor je werkt. Naast dat, heeft rsh ook een security probleem (gespoofde host namen). Als je niet wil of kan gebruik maken van rsh, kun je het ook handmatig transporteren, zoals dit:

light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Pass-word:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
dark% xfig &
[15332]
dark% log out
light$

Zie ook rsh(1) en xauth(1) voor meer informatie

Het is mogelijk om de cookie te transporteren met het TERM variabel of DISPLAY variabel als je tel-net doet naar een remote host. Dit werk het zelfde als het transporteren van het DISPLAY variabel met het TERM variabel. Zie Sectie 5: De client vertellen.

De Cookie gebruiken

Een X applicatie op dark.matt.er, zoals xfig, zal automatisch kijken in ~/.Xauthority om zichzelf te legaliseren.

Er is een klein probleem als je gebruikt localhost:D. X client applicaties kunnen dit vertalen in host/unix:D voor het doel om de cookie te ontvangen. Dat betekend dat de cookie voor localhost:D in je ~/.Xauthority geen zin meer heeft.

6.3 Ssh

Authorizatie records worden gezonden zonder encryptie. Als bang bent dat iemand je connectie afluistert, gebruik dan ssh, de secure shell. Het gebruikt X forwarding over geëncrypte connecties. En daarnaast is het geweldig op andere manieren. Het is een goede structurele toevoeging aan je systeem. Ga naar http://www.cs.hut.fi/ssh/ , de ssh home page.

Wie weet er andere manieren voor legaliserings schema's of encrypted X connecties? Misschien kerberos?


Verder Terug Inhoud