Опубликован: 20.02.2007 | Доступ: свободный | Студентов: 3481 / 786 | Оценка: 4.42 / 4.03 | Длительность: 40:03:00
Лекция 3:

Система X Window

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >

Безопасность X Window, часть 1: использование xhost и xauth

Поскольку X Window взаимодействуют с вашей клавиатурой, мышью и экраном, оставлять X Window незащищенным слишком опасно. Это не только даст возможность кому бы то ни было выводить окна на ваш дисплей, но и кто угодно сможет запустить "невидимое" приложение, которое сможет перехватывать информацию от клавиатуры или от мыши. Вы можете использовать два встроенных метода для блокирования X-сервера - xhost и xauth.

Xhost

Xhost позволяет осуществлять контроль за доступом к вашему X-серверу на основе имени хоста/IP-адреса. Чтобы разрешить машине HOST2 использовать HOST1 в качестве дисплея, вам необходимо убедится, что X-сервер машины HOST1 запущен с помощью следующей команды (например, с использованием окна X-терминала):

bash% xhost +HOST2

Если вы хотите явным образом запретить доступ для HOST2, то попытайтесь сделать это так:

bash% xhost -HOST2

По умолчанию доступ запрещен для всех. Вы можете использовать xhost, чтобы добавить определенные хосты в специальный список доверенных хостов. Вы можете также разрешить доступ на глобальном уровне (отменив контроль доступа) просто запустив команду xhost +. Это делать не рекомендуется, поскольку некто, имеющий доступ к вашей машине по сети, будет иметь возможность запускать приложения на вашем X-сервере. Команда xhost - позволяет вновь включить контроль доступа к использованию X-сервера, разрешая доступ только для хостов, внесенных в список доверенных. Чтобы просмотреть список машин, которым в настоящее время разрешено использовать ваш X-сервер, запустите команду xhost без параметров.

Примечание. Команда xhost запрещает доступ только "на будущее"; эта команда не прерывает текущие соединения.

Тем не менее, Xhost - не слишком эффективный метод обеспечения контроля доступа, поскольку он не требует аутентификации на основе ввода имени пользователя и пароля, а также не использует шифрования. По той же самой причине базовый контроль доступа, основанный на контроле IP-адреса на брандмауэре - не слишком хорошее решение для Виртуальной частной сети (VPN - Virtual Private Network); вы полагаетесь исключительно на IP-адрес для определения идентичности. Как мы уже видели и увидим в последующих лекциях, имя хоста или IP-адрес могут быть подделаны. Для пользователей, хорошо знакомых с TCP-оболочкой и запуском удаленных служб ( rsh, rlogin и т.д.), это похоже на веру в то, что файлы hosts.allow, hosts.deny и hosts.equiv защитят ваши X-сессии.

Совет. Использование xhost + может переопределить все средства обеспечения безопасности, обсуждающиеся в нескольких следующих разделах. Вам следует всячески избегать запуска этих команд без определения имени хоста.
Xauth

Xauth в действительности является не программой контроля доступа, а скорее, графическим интерфейсом пользователя для доступа к файлу Xauthority, который может использоваться X-сервером для обеспечения безопасности. Xauth позволяет добавлять, удалять, просматривать и объединять списки авторизации для доступа к X-серверу. Элементы списка авторизации для доступа к X-серверу содержат имя хоста X-сервера и номер дисплея, протокол авторизации и секретные данные. X-сервер должен при запуске сгенерировать список авторизации на основе своего файла Xauthority (это делает программа xdm ), а клиенты, желающие получить доступ к этому серверу, должны иметь строку авторизации в своем локальном файле Xauthority. X Window-авторизация поддерживает несколько различных протоколов. В этой книге рассматривается только два из них.

  • MIT-MAGIC-COOKIE-1. Это наиболее популярный протокол, поскольку он проще в использовании и не требует использования программы xdm (о которой мы кратко поговорим позже). Для обеспечения секретности используется 128-битный ключ, который можно скопировать из Xauthority -файла на сервере в соответствующий файл клиента, используя программу xauth. Когда сервер вызывает клиента, секретный ключ передается в виде простой текстовой строки.
  • XDM-AUTHORIZATION-1. Практически то же самое, что и предыдущий протокол, но использует стандарт шифрования DES, чтобы не пересылать по сети секретный ключ в виде простого текста. В данном случае используется зашифрованный 56-битный секретный ключ и 64-битная строка аутентификации. Когда клиент производит соединение, сервер вызывает его, запрашивая 192-битный пакет данных (содержащий дату, время и идентификационную информацию) который зашифрован с использованием открытого ключа. Если клиент располагает правильным ключом и сервер может расшифровать и интерпретировать информацию, клиент получает разрешения на доступ.
Примечание. В данном контексте ключи xauth, xauth cookies и Xauthority - элементы, являющиеся синонимами.

Концепция довольно проста. После запуска X-сервера необходимо сгенерировать запись в файле Xauthority в зависимости от того, какой протокол вы используете. Если вы используете xdm, запись будет сгенерирована автоматически. Многие системы могут автоматически генерировать запись, когда вы вручную запускаете X-сервер. Поговорим о том, как можно сгенерировать Xauthority -запись вручную, чтобы вы представляли себе команды, которые при этом выполняются. Например, будем использовать протокол MIT-MAGIC-COOKIE-1.

На машине, где запущен X-сервер, запустите xterm. Наберите следующие команды.

jdoe@myxserver$ xauth
xauth: creating new authority file /home/jdoe/.Xauthority
Using authority file /home/jdoe/.Xauthority
xauth generate myxserver:0 .
authorization id is 41
xauth list
myxserver:0 MIT-MAGIC-COOKIE-1  121812483b0b3f19367c1541062b472b
xauth
Совет. Точка в конце команды generate находится в том месте, где следовало бы определить протокол аутентификации, который вы бы хотели использовать для xauth. Если использовать только точку, то будет использоваться протокол MIT-MAGIC-COOKIE-1. Создание записи для другого протокола обычно требует дополнительной информации, которую необходимо добавить в конце командной строки. Обычно это делается не вручную, а с использованием внешней программы или скрипта.

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

jdoe@remotebox$ xauth add myxserver:0 MIT-MAGIC-COOKIE-1 \
21812483b0b3f19367c1541062b472b

Или вы можете слегка автоматизировать этот процесс.

jdoe@myxserver$ xauth extract - $DISPLAY | ssh remotebox "xauth merge -"

Команда xauth извлечет ключ для хоста, названного в переменной $DISPLAY и пошлет его на стандартный вывод. Мы перенаправим этот вывод на remotebox с использованием ssh и добавим эту информацию к команде xauth. Это эффективный способ передачи ключа для авторизации с сервера в Xauthority -файл на удаленной машине. Вы можете подтвердить это, запросив список авторизационных записей на удаленной машине. Удаленная машина теперь может свободно использовать X-сервер с машины myxserver, поскольку ей известен ключ для авторизации. Только хосты, которым известен ключ авторизации, могут использовать X-сервер.

Совет. Предыдущая команда предполагает, что в переменной DISPLAY содержится IP-адрес или имя хоста. Имейте в виду, что переменная DISPLAY может ссылаться на другое, нежели интернет, семейство адресов. Если переменная DISPLAY установлена в :0 и вы запускаете команду, то можете обнаружить, что записи в файле Xauthority удаленной машины ссылаются на myxserver по только ей известному имени (имени нет в базе DNS), или, что еще хуже, по адресу, принадлежащему другому семейству адресов (например, по адресам сокетов локального домена вместо адресов TCP/IP). Поэтому наилучшим можно признать однозначное задание IP-адреса в переменной DISPLAY (например, в виде 192.168.1.50:0).

Передача записей из файла Xauthority от сервера клиенту одинакова независимо от типа используемого протокола авторизации. Некоторые из более продвинутых протоколов включают процедуру SUN-DES-1, которая использует систему Secure RPC от фирмы Sun, и MIT-KERBEROS-5, которая использует аутентификацию пользователей по протоколу Kerberos. Эти методы авторизации более безопасны, но они также и более сложны для первоначальной настройки. За подробной информацией обращайтесь к man-страницам по процедурам xauth, xdm, и по файлу Xsecurity.

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >