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.
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).
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.
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
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 -
~/.Xauthority
(xauth nlist :0
).| rsh dark.matt.er
).~/.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.
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.
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?