6. 서버 일려주기(Telling the Server)

서버는 아무 곳으로부터 접속을 허락하진 않을 것이다. 당신은 당신의 스크린에 아무나 윈도우를 열 수 있는 것을 원하지 않는다. 혹은 당신이 타이프한 것을 아무나 읽을 수 있는 것을 원하지 않는다. -- 당신의 키보드는 당신 디스플레이의 일부임을 기억하라!

소수의 사람들은 지나치게 디스플레이에 억세스를 허락하는 것을 보안 위험성을 높이는 것으로 재 정의하는 것같다. 당신의 디스플레이에 억세스 중인 누군가가 당신의 스크린들에 읽고 쓰기와, 당신이 누른 키 읽기와, 당신의 마우스 동작 읽기를 할 수는 있다.

대부분의 서버들은 서버에 연결을 인증하는 방법 두 가지를 알고 있다. host list mechanism (xhost)과 magic cookie mechanism (xauth)이 그것이다. 그 다음으로는 ssh(the secure shell)이 있는데 엑스 윈도우 연결을 향상시킬 수 있다.

6.1 Xhost

Xhost는 호스트 이름에 근거를 두고 엑세스를 허락한다. 서버는 서버에 연결을 허락한 호스트 목록을 유지한다. 역시 호스트 확인을 완전히 불가능하게 할 수도 있다. 주의하라: 이것은 확인을 전혀 하지 않게 됨을 의미한다. 그래서 모든 호스트가 연결이 가능할 것이다!

당신은 xhost 프로그램으로 서버의 호스트 목록을 관리할 수 있다. 이전의 예에서 이 기법(mechanism)을 이용하기 위해서는, 이렇게 하라:

light$ xhost +dark.matt.er

이것은 호스트 dark.matt.er로부터 모든 연결을 허락한다. 당신의 엑스 윈도우 클라이언트가 연결을 만들어 창을 하나 표시하자마자, 안전을 위하여, 아래 명령으로 현재 열린 창 이후에 연결을 위한 허가를 무효로 한다:

light$ xhost -dark.matt.er

당신은 호스트 확인을 아래 명령으로 불가능하게 할 수 있다:

light$ xhost +

이것은 호스트 억세스 확인을 불가능하게 하여 누구에게나 연결을 허락한다. 모든 이용자를 당신이 신뢰할 수 없는 네트워크(인터넷 같은)상에선 결코 이 명령을 내려선 안된다. 당신이 아래 명령으로 호스트 확인을 다시 가능하게 할 수 있다:

light$ xhost -

xhost - 그 자체는 억세스 리스트로부터 모든 호스트들을 제거하지 않는다 (모두 제거하는 명령은 별로 쓸모 없을 것이다 - 당신은 어느 곳으로부터도 연결할 수 없을 것이다, 심지어 당신의 로컬 호스트로부터도 연결할 수 없을 것이다).

Xhost는 대단히 위태로운 방법이다. 원격 호스트에 여러 사용자들 관에 구분을 하지 않는다. 역시, 호스트 이름(실제 주소)은 눈속임을 당할 수 있다. 이것이 당신이 신뢰할 수 없는 네트워크 (예를 들어 인터넷에 이미 전화선을 이용한 PPP 억세스를 한 상태)상에 있다면 바람직하지 않다.

6.2 Xauth

Xauth는 올바른 열쇠를 아는 사람에게 억세스를 허락한다. 열쇠는 authorization record나 magic cookie로 불리는 것 따위이다. 이 인가 방법는 정식으로 MIT-MAGIC-COOKIE-1라 불린다.

여러 개의 디스플레이에 대한 쿠키들은 ~/.Xauthority에 함께 저장한다. 당신의 ~/.Xauthority은 그룹 구성원이나 다른 사용자들이 가까이하기 어려운 것임에 틀림없다. xauth 프로그램은 이 쿠키들을 관리한다, 여기서부터 이 방법은 약칭으로 xauth라 하겠다.

한 세션이 시작함과 동시에, 서버는 -auth 옵션이 가리키는 파일로부터 쿠키 하나를 읽는다. 그리고 나서, 서버는 동일한 쿠키를 숙지하고 있는 클라이언트로 부터의 연결만을 허락한다. ~/.Xauthority에 쿠키가 바꾸었을 경우에, 서버는 바뀐 것을 손에 넣으려 하지 않을 것이다.

서버는 클라이언트에게 몹시 분주하게 요구하는 쿠키를 결코 생성할 수 없다. 그렇지만 쿠키들은 서버 내부에 무사히 보존된다; 클라이언트가 서버에 쿠키들을 덮어쓰지 않는다면 쿠키들은 ~/.Xauthority에서 없어지지 않는다. David Wiggins에 의하면:

당신이 관심을 가지고 있을지 모르는 앞선 묘안을 X11R6.3에 추가했다. 새로운 ``보안'' 확장에 의하여, 엑스 서버 자체가 몹시 분주하게 새로운 쿠키를 생성시키고 되돌릴 수 있다. 더군다나, 쿠키들은 ``신뢰할 수 없다''고 지적될 수 있어서 그러한 쿠키들로 연결을 한 응용프로그램은 실행 중에 제지될 수 있다. 예를 들어, 신뢰할 수 없는 것들은 키보드/마우스 입력이나 윈도우 콘텐츠를 여러 신뢰성 있는 클라이언트들로부터 손에 넣을 수 없을 것이다. 안심하기 어렵다면, 웬만한 실력으로도 사용 가능한 새로운 ``생성'' 하부명령이 있다.

xauth는 xhost 사용상에서 명백한 보안상 이점을 가진다. 당신은 특정한 컴퓨터 상에 특정한 사용자로부터의 억세스를 제한할 수 있다. xauth는 xhost처럼 주소를 속이는 일에 고생하지 않는다. 그리고 당신이 원한다면, xauth가 연결을 허락한 다음에 xhost를 계속 사용할 수 있다.

쿠키 생성하기(Making the Cookie)

xauth를 사용하기 원한다면, 당신은 X server를 -auth authfile 옵션으로 시작해야 한다. 당신이 startx 스크립트를 사용한다면, 그 스크립트가 xauth를 사용하기 위한 적절한 장소이다. 당신의 startx 스크립트에 아래와 같이 authorization record를 만들어라.

/usr/X11R6/bin/startx로부터 발췌:

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

Mcookie는 리눅스-유틸 패키지(주요 사이트는 ftp://ftp.math.uio.no/pub/linux/) 속에 아주 작은 프로그램이다. 택할만한 것으로, 당신은 임의의 무작위 데이타(예를들어, /dev/urandom나 ps -axl같은데로부터)를 추출해서 쿠키 형태 속에 넣기 위해 md5sum을 사용할 수 있다:

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

당신이 startx 스크립트를 (root가 아니라서) 편집할 수 없다면, startx를 정확히 설정하기 위해 시스템 관리자 권한을 얻거나, 대신에 관리자가 xdm을 설정하게 하라. 관리자가 할 수 없었거나 하려고 하지 않는다면, 당신은 ~/.xserverrc 스크립트를 만들 수 있다. 당신이 이 스크립트를 가지고 있다면, xinit에 의해 실재 X server 대신에 이 스크립트가 실행된다. 그리고 나서 당신은 이 스크립트에서 적당한 옵션으로 실재 X server를 시작할 수 있다. 그렇게 하려면, 당신의 ~/.xserverrc가 쿠키 하나를 먼저 만들고나서 magic cookie 행을 실행하고 이어서 실재 X server를 실행하도록 해라:

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

DisplayManager.authDir: /var/lib/xdm

쿠키 전달하기(Transporting the Cookie)

이제 막 당신은 서버 호스트 light.uni.verse에 당신의 X 세션을 시작하고 ~/.Xauthority에 당신의 쿠키를 얻었다, 당신은 클라이언트 호스트 dark.matt.er에 쿠키를 전해야 할 것이다.

당신의 홈 디렉토리가 밤낮으로 공유되어 있으면 가장 쉬운 경우이다. ~/.Xauthority 파일들은 단조롭다, 그래서 쿠키는 순간적으로 전달된다. 그러나, 붙들릴 수도 있다: 당신이 ~/.Xauthority에 :0에 대한 쿠키 하나를 붙일 때, dark 컴퓨터는 light컴퓨터를 위한 것이 아니고 dark컴퓨터를 위한 것으로 여길 것이다. 당신은 쿠키를 만들 때 뚜렷한 호스트 이름을 사용해야 한다; 당신은 그것을 무시할 수 없다. 당신은 :0과 light:0를 위한 쿠키를 같은 것으로 인스톨할 수 있다:

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

홈 디렉토리가 공유되어있지 않다면, 당신은 rsh(the remote shell)로 쿠키를 전달할 수 있다:

light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge -

1. 당신의 로컬 ~/.Xauthority에서 쿠키를 빼낸다 (xauth nlist :0).
2. 쿠키를 dark.matt.er에 전달한다 (| rsh dark.matt.er).
3. 거기 ~/.Xauthority에 쿠키를 붙인다 (xauth nmerge -).

rsh가 당신을 위해 동작하지 않고 있는 경우도 있을 수 있다. rsh은 게다가, 보안상 약점(내 기억이 옳다면, 호스트 이름을 거짓으로 대답하는데 속을 수 있다)도 가지고 있다. 당신이 rsh를 사용할 수 없거나 바라지 않는다면, 당신은 다음과 같이 쿠키를 수동으로도 전달할 수 있다:

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

더 많은 정보를 얻으려면 역시 rsh(1)와 xauth(1x)의 맨페이지를 보기 바란다.

당신이 원격 호스트에 telnet 접속을 할 때 TERM이나 DISPLAY 변수 속에 쿠키를 같이 전달하는 것이 가능할지 모른다. 이것은 TERM 변수 내에 DISPLAY 변수를 같이 전달하는 것과 똑같은 방법이 통할 것이다. 5장 : 클라이언트 알려주기(Telling the Client)를 보아라. 나의 지침을 토대로 이 부분은 당신 자신의 힘으로 해보라, 그러나 나는 누군가가 이것을 확인이나 부정을 할 수 있는지 궁금하다.

쿠키 사용하기(Using the Cookie)

dark.matt.er상에, xfig같은 뛰어난, X 응용프로그램은 저절로 자신을 인증받기 위한 쿠키를 그 컴퓨터에 ~/.Xauthority에서 조사해 볼 것이다.

6.3 Ssh

Authority record들은 암호화하지 않고 발송한다. 당신이 누군가가 당신의 연결을 엿보는 것을 걱정 해보았다면, ssh(the secure shell)을 사용하라. 암호화된 연결 상에서 X protocol 연결을 향상시킬 것이다. 게다가, 그 외에 좋은 점도 있다. 그 외에 좋은 점으로는 당신의 시스템에 좋은 구조상의 개선이 있다. 그냥 http://www.cs.hut.fi/ssh/, ssh 홈페이지를 방문해 보라.

인증 방법이나 암호화 X 연결에 관해서 이 밖에 다른 것을 아는 사람이 있겠는가? 아마 지옥을 지키는 개(Kerberos)가 알고 있을까?