Как работает авторизация x11? (MIT Magic Cookie)

Question

Меня интересует подробный ответ, объясняющий, как именно работает авторизация x11 и особенно MIT Magic Cookies.

Я понимаю, что на самом деле это запрещает доступ ко всем остальным, кроме зарегистрированного пользователя, а также некоторые механизмы управления, которые контролируют клиентское приложение, которое может подключаться к серверу Xdisplay или нет.

Я также обнаружил, что существует пять стандартных механизмов контроля доступа и их можно разделить на три основные категории:

. Доступ на основе хоста

. Доступ на основе печенья

. Доступ на основе пользователя

Но с этого момента и на самом деле я не понимаю, как они работают, и какими способами они точно используют, чтобы выполнять авторизацию.

Answer 1

Ну, во-первых, на машине есть файл ~/.Xauthority. Обратите внимание, что (как правило, на компьютере с GUI) неправильные разрешения этого файла, может вызвать цикл экрана входа в систему ... (мне потребовалось много часов, чтобы это понять).

Как упоминалось есть 5 механизмы:

1. доступа Ведущий: сервер имеет список доступа хоста (если сетевой адрес существует в этом списке, то соединение разрешено). управление списком осуществляется с помощью команды xhost. ПРИМЕЧАНИЕ. Это не позволяет одновременно использовать более одного соединения. Я не знаю больше об этом методе, потому что я действительно не использовал его. но вы можете увидеть man Xserver, предоставляющий доступ раздел :)

2. MIT-MAGIC-печенье-1: Генерация ключа 128bit ("куки"), хранить его в ~/.Xauthority (или где точки XAUTHORITY envvar к). Клиент отправляет его на сервер plain! сервер проверяет, есть ли у него копия этого «cookie», и если да, соединение разрешено. ключ генерируется DMX.

3. XDM-authorization-1: Опять же, есть ключ, хранящийся в ~/.Xauthority. этот ключ состоит из двух частей - ключа шифрования DES-56 бит и 64 бит случайных данных, используемых в качестве аутентификатора. При подключении к серверу клиент генерирует 192 бита данных: ctime в сочетании с идентификатором 48 бит (для tcp/ip: ip address + port, для локальных подключений это идентификатор PID и 32-битный уникальный идентификатор). ключ DES используется для шифрования данных и затем отправляется на сервер. сервер проверяет пользователя, расшифровывая его, затем проверяя аутентификатор 64 бит и дополнительные данные.

4. sun-des-1: он использует асимметричное шифрование, сервер имеет открытый ключ, который он использует для дешифрования входящих запросов. он также использует «список хостов». Это требует некоторых дополнительных механизмов в сети, у меня нет такой сети, поэтому я не очень хорошо понимаю этот механизм.

5. сервер интерпретируется: он может быть реализован по-разному ... но в общем случае клиент отправляет 2 строки на сервер. Вторая строка - это запись пользователя (например, имя пользователя), а первая строка - тип записи (например, localuser).

ПРИМЕЧАНИЕ: второй, третий и 4-й механизмы хранения ключей внутри ~/.Xauthority поэтому каждый, кто имеет доступ к этому файлу, может подключиться к серверу, притворяясь «ты».

Команда xauth может анализировать файл Xauthority и извлекать интересные значения.

$ 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> 

• Данные изменены ....