Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

X Window.

Рубрика: Безопасность -> Безопасность рабочей станции
Метки: | |
Среда, 20 мая 2009 г.
Просмотров: 5665

Раньше было написано про модель клиент/сервер, которая применяется для системы графического интерфейса Unix - X Window - X11. Система X Window представляется сетевой системой, поэтому можно свободно запустить X11-приложение на удаленной машине и видеть результат его выполнения в X11-сессии своей машины. Можно отметить, что процесс будет выполняться на удаленной машине, а вы будете видеть только результат. На удаленной машине можно:


  • Делать снимки экрана.
  • Отправлять события (нажатия клавиш и передвижение мыши).
  • Перехватывать события.

     Для ограничения доступа к X11-серверу применяется два метода: аутен­тификация по имени узла (host-based authentication) и аутентификация по токену (token-based authentication). Про оба способа написано ниже.

     Аутен­тификация по имени узла.

     Это самый часто используемый и менее всего безопасный метод. Доступ к серверу дается, если IP-адрес или имя машины Х11-клиента указано в списке доступа. Посмотреть и изменить список доступа нужно с помощью команды xhost:

$ xhost

access control enabled, only authorizd clients can connect

INET:zulus.zulus

INET:192.168.1.3

INET:192.168.1.77

     Для добавления узла используется команда:

$ xhost +192.168.5.7

192.168.5.7 being added to access control list

     Для удаления применяется похожая команда, только перед именем/адре­сом узла надо указать минус, а не плюс:

$ xhost -homosape

homosape.primer.com being removed from access control list

     Если нужно разрешить подключаться к серверу абсолютно всем клиентам, надо выполнить команду:

$ xhost +

access control disabled, clients can connect from any host

     Чтобы заново включить контроль доступа к X11-серверу, надо использовать ко­манду:

$ xhost -

access control enabled, only authorizd clients can connect

     Основная проблема списка доступа заключается в следующем: если раз­решить доступ определенному узлу к серверу, то будет разрешен доступ всем пользователям этого узла. Дальше объяснять не нужно.

     Аутентификация по токену.

     Кроме аутентификации по узлу, X11 дает альтернативный метод аутентификации, который использует токены. Токен - это магический ключ, который обязан быть предоставлен клиентом, который хочет получить доступ. Этот ключ создается менеджером дисплея xdm (X Display Manager), но, если можно, он может быть создан пользователем. Ключ хранится в файле ~/ .Xauthority.

     Для локального пользователя изменение способа аутентификации незаметно, но удаленные клиенты разницу заметят. Прежде всего нужно сообщить им магический Cookie. Для извлечения этого Cookie из файла .Xauthority (со стороны сервера) и передачи его в файл .Xauthority клиента можно употреблять команду xauth:

$ xauth extract -$DISPLAY | ssh den@remote.host xauth merge -

     В этом примере прежде всего извлекается токен для текущего дисплея (он задан переменной окружения SDISPLAY) и, используя перенаправление ввода-вывода, он отправляется команде xauth merge, запущенной на удаленном узле. Как только Cookie передано, клиент может подключаться к серверу.

     В отличие от аутентификации, основанной на имени узла, применение токена дает гарантию, что к серверу подключится только один определенный пользователь удаленного узла. Передается токен определенному пользователю (mаn) узла remote.host. Из-за того, что токен - это секретная информация, нужно обеспечить ее безопасность. Для этого установливаются права доступа к файлу .Xauthority равными 600 (chmod 600 . Xauthority), и нужно убедиться, что домашний каталог пользователя не экспортируется по NFS или Samba.

     Как видно, недостаток этого способа аутентификации заключается в его более сложной настройке. Можно знать, как работает X11, настроить ssh на компьютере клиента (если sshd настраивали не вы, то вам надо знать пароль этого пользователя). Зато употребление этого метода с точки зрения безопасности себя полностью оправдывает.

     Нужно учесть, что xhost-схема имеет больший приоритет, чем xauth, и в случае возникновения конфликта он будет разрешен в пользу xhost.