Все инструментальные средства, которые мы рассматривали до сих пор, представляли собой утилиты командной строки. Мы запускали их из командной строки, задавая параметры и входную информацию в командной строке, и получали выходную информацию на экран или в файл. Некоторые программисты считают утилиты командной строки сложными и менее функциональными, в то время как другие считают их более эффективными и менее тяжеловесными. В любом случае утилиты командной строки не могут выполнять свою задачу так легко, как бы этого хотелось.
Графические утилиты могут помочь вам визуализировать данные и представить их в удобной для анализа форме. Оконная подсистема Windows является ядром этой операционной системы. Вы не можете установить Windows XP с интерфейсом командной строки, не устанавливая
Эта система понадобится вам для знакомства со следующими программами в этой книге. Ее краткое описание продемонстрирует, как она работает, и как обеспечить ее безопасную работу. Установка и возможности настройки этой системы весьма обширны и в этой книге не обсуждаются, но мы постараемся дать вам общее представление о том, что происходит в X Window. Мы также коснемся нескольких свойственных этой системе проблем с безопасностью, чтобы вы помнили о них.
Простейшая, но важная деталь, касающаяся X Window, состоит в том, что по умолчанию она поставляется без оконного менеджера или рабочего стола. X Window поддерживает клавиатуру, мышь, и окно для вывода информации. Оно поставляется с базовой системой, которая позволяет вам "поместить" окна в любое место на экране и уничтожить эти окна. Причудливые меню и панели инструментов отставлены для оконных менеджеров, которые выполняются поверх X Window. В настоящее время доступно несколько оконных менеджеров, включая такие популярные приложения как Gnome, KDE, и Window Maker. Эмуляторы X Window для системы Window вроде ReflectionX или Exceed также имеют собственные встроенные оконные менеджеры. Важно помнить, что X Window - всего лишь промежуточная архитектура для оконной системы; в ней нет ничего, что бы выглядело, как графическая оконная среда.
X Window использует xemacs, взаимодействие между клиентом и сервером довольно прозрачно. Внешне это выглядит, как если бы это была машина под управлением Microsoft Windows.
Но что, если вы запустите X сервер на машине с именем HOST1, соединитесь с помощью telnet с машиной HOST2, и захотите запустить на HOST2 редактор xemacs? Вам понадобиться указать xemacs-клиенту на HOST2, что необходимо использовать X сервер на машине HOST1. Если вы думаете об этом, то именно в этом состоит глубокий смысл архитектуры клиент/сервер. Обычно, если вы работаете в системе, и вам требуется использование удаленных ресурсов, вы используете локальные клиентские приложения для соединения с удаленным сервером, который предоставляет ресурсы. В случае с X Window, вы запускаете сервер на своей локальной машине, а затем удаленный ресурс (клиент) устанавливает соединение с вами.
Предположим, вы вошли в систему в командной строке (с использованием интерпретатора bash или tcsh ) на HOST2. Вы можете указать системе на HOST2 использовать HOST1 для отображения графических приложений, задав это в командной строке X приложения, которое вы запускаете.
HOST2% xemacs -display HOST1:0.0
Вы можете заставить все X приложения использовать HOST1 по умолчанию для отображения, установив переменную окружения DISPLAY внутри среды командного интерпретатора. Для этого в командной строке HOST2 вы должны выполнить:
HOST2% DISPLAY=HOST1:0.0; export DISPLAY
Для Bourne shell ( sh, bash ), или:
HOST2% setenv DISPLAY HOST1:0.0
для C shell ( tcsh ).
Теперь если вы запустите xemacs, то вместо попыток отображать информацию на HOST2 (на котором может быть запущен X сервер, а может, и нет), он будет пытаться отображать данные на HOST1. Ниже приводятся иллюстрации работы модели клиент/сервер.
Что означает значение :0.0 после строки HOST1 в переменной DISPLAY? Один хост теоретически может выполнять несколько X серверов. Каждый X сервер может управлять несколькими экранами. Формат переменной DISPLAY выглядит следующим образом:
DISPLAY = <hostname>:<displaynumber>.<screennumber>
где:
Если вы не используете необычную конфигурацию X-сервера, значение переменной DISPLAY всегда должно быть равным :0.0. Фактически, вам следует оставить только значение .0, поскольку экран с номером 0 используется по умолчанию.
X-серверы по умолчанию прослушивают TCP-порт с номером 6000. Если на той же самой машине был запущен второй X-сервер (дисплей), он будет прослушивать TCP-порт с номером 6001. Номер дисплея, который будет использовать X-сервер, всегда будет поставлен в соответствие TCP-порту с номером, образованным сложением 6000 с номером дисплея.
Вы можете обратить внимание на небольшую проблему с безопасностью в такой модели клиент/сервер. Задание переменной окружения позволяет нам сообщить клиенту на HOST2 отображать информацию на HOST1. Но что остановит вас от передачи информации от приложения куда ни будь еще? Один из наиболее распространенных способов взлома, рассматриваемых на тренингах по безопасности систем, является определение в переменной DISPLAY параметров вашего собственного X-сервера и наблюдение за тем, как вы запускаете все новые версии программы xeyes на своем рабочем столе всякий раз, когда пытаетесь что-либо сделать. Наиболее пугающим злоупотреблением может быть запуск программы вроде xkey, которая перехватывала бы все вводимые вами символы от X-сервера. Очевидно, что X-сервер должен иметь некоторые способы контроля доступа, чтобы только полномочные клиенты могли выводить свою информацию.
Поскольку X Window взаимодействуют с вашей клавиатурой, мышью и экраном, оставлять X Window незащищенным слишком опасно. Это не только даст возможность кому бы то ни было выводить окна на ваш дисплей, но и кто угодно сможет запустить "невидимое" приложение, которое сможет перехватывать информацию от клавиатуры или от мыши. Вы можете использовать два встроенных метода для блокирования X-сервера - xhost и xauth.
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 - rsh, hosts.allow, hosts.deny и hosts.equiv защитят ваши X-сессии.
xhost + может переопределить все средства обеспечения безопасности, обсуждающиеся в нескольких следующих разделах. Вам следует всячески избегать запуска этих команд без определения имени хоста.Xauth в действительности является не программой контроля доступа, а скорее, графическим интерфейсом пользователя для доступа к файлу Xauthority, который может использоваться X-сервером для обеспечения безопасности. Xauth позволяет добавлять, удалять, просматривать и объединять списки авторизации для доступа к X-серверу. Элементы списка авторизации для доступа к X-серверу содержат имя хоста X-сервера и номер дисплея, протокол авторизации и секретные данные. X-сервер должен при запуске сгенерировать список авторизации на основе своего файла Xauthority (это делает программа xdm ), а клиенты, желающие получить доступ к этому серверу, должны иметь строку авторизации в своем локальном файле Xauthority. X Window-авторизация поддерживает несколько различных протоколов. В этой книге рассматривается только два из них.
xdm (о которой мы кратко поговорим позже). Для обеспечения секретности используется 128-битный ключ, который можно скопировать из Xauthority -файла на сервере в соответствующий файл клиента, используя программу xauth. Когда сервер вызывает клиента, секретный ключ передается в виде простой текстовой строки.xauth, xauth cookies и Xauthority - элементы, являющиеся синонимами.Концепция довольно проста. После запуска X-сервера необходимо сгенерировать запись в файле Xauthority в зависимости от того, какой протокол вы используете. Если вы используете xdm, запись будет сгенерирована автоматически. Многие системы могут автоматически генерировать запись, когда вы вручную запускаете X-сервер. Поговорим о том, как можно сгенерировать Xauthority -запись вручную, чтобы вы представляли себе команды, которые при этом выполняются. Например, будем использовать протокол MIT-MAGIC-COOKIE-1.
На машине, где запущен X-сервер, запустите
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
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), или, что еще хуже, по адресу, принадлежащему другому семейству адресов (например, по DISPLAY (например, в виде 192.168.1.50:0).Передача записей из файла Xauthority от сервера клиенту одинакова независимо от типа используемого протокола авторизации. Некоторые из более продвинутых протоколов включают процедуру SUN-DES-1, которая использует систему Secure RPC от фирмы Sun, и MIT-KERBEROS-5, которая использует аутентификацию пользователей по протоколу Kerberos. Эти методы авторизации более безопасны, но они также и более сложны для первоначальной настройки. За подробной информацией обращайтесь к man-страницам по процедурам xauth, xdm, и по файлу Xsecurity.
Теперь вы можете лучше контролировать доступ к вашему X-серверу, но по прежнему все данные X-сервера передаются по сети открытыми. Несмотря на то, что X-трафик весьма трудно реконструировать (выделить движения мыши и графику среди другой информации), вы можете захотеть добавить шифрование.
Протокол SSH (Secure Shell) дает возможность перенаправить TCP-соединения через SSH-туннель. Если в вашем распоряжении имеется SSH-клиент, который поддерживает перенаправление по протоколу X11, то вы можете зашифровать свои X Window-соединения.
Вновь вернемся к упоминавшемуся ранее примеру с машинами HOST1 и HOST2. Предположим, что мы запустили сервер X Window на машине HOST1, и хотим выполнить клиентское приложение на HOST2 и передавать информацию для отображения на HOST1. Реализация протокола SSH на обеих машинах должна допускать перенаправление X11-трафика (обычно это допускается по умолчанию). Далее следует убедиться, что на SSH сервере на машине HOST2 включена поддержка перенаправления X11 трафика, и для SSH-клиента на машине HOST1 также включена такая поддержка. Вы можете это проверить, просмотрев файлы ssh_config и sshd_config в соответствующей директории (размещающейся в разных местах в зависимости от типа используемой системы, но обычно в директории /etc/ssh ). Проверьте строки X11Forwarding или ForwardX11 и установите параметр "yes", если хотите, чтобы это работало.
ssh_config, можно включить с помощью флага -x. В то же время, перенаправление X11-трафика для SSH-сервера включено по умолчанию, и изменить это можно только в файле sshd_config.С помощью флага -x определим использование перенаправления трафика X11 от HOST1 к HOST2 через SSH. Теперь просмотрим содержимое переменной DISPLAY на HOST2, воспользовавшись командой setenv | grep DISPLAY (для интерпретатора tcsh ) или set | grep DISPLAY (для интерпретатора sh и bash ). Вы должны увидеть нечто похожее на строку
DISPLAY=HOST2:10.0
Но минуточку! Номер дисплея равен 10, а хост - HOST2. Но вы хотели отображать вывод X Window приложения на HOST1. Переменная DISPLAY устанавливается автоматически, как только вы осуществите SSH-соединение с флагом -x. Дисплей номер 10 на HOST2 автоматически назначается на локальный X-сервер, чтобы отображать информацию через SSH на реальном X-сервере на HOST1. Попытайтесь теперь выполнить приложение xclock на HOST2, и вы увидите часики на экране HOST1. Все ваши действия с приложением будут передаваться через шифрованный туннель. Шифрование не строго обязательно, когда вы запускаете удаленно часы, но это может оказаться важным, когда вы используете удаленный запуск редактора xemacs.
-display с любой из команд X Window, если они выполняются через SSH-туннель, поскольку это переопределит специальный "доверенный" сервер, который определяет SSH.Перенаправление X11-трафика через SSH также касается и аутентификации. Вдобавок к автоматическому определению "доверенного" X-сервера, SSH клиент определяет фиктивный идентификационный набор информации и направляет его SSH-серверу. Сервер, в свою очередь, записывает идентификационную информацию в Xauthority файл на удаленной машине, автоматически предоставляя вам доступ к вашему X серверу. Другими словами, если вы запускаете X-сервер на HOST1, SSH-клиент должен сообщить "доверенному" X-серверу на SSH-сервере о необходимости создать следующую запись в Xauthority -файле на HOST2.
HOST2:10 MIT-MAGIC-COOKIE-1 121812483b0b3f19367c1541062b472b
Это предохраняет от передачи реальной идентификационной информации через сеть. В обоих направлениях пересылается только фиктивная идентификационная информация (да и та зашифрованная). Соединения, которые проходят через прокси, могут поставить в соответствие фиктивную идентификационную информацию для HOST2:10 реальным данным для HOST1:0. Это позволяет осуществить перенаправление X-трафика через SSH-туннель к серверу только авторизованному X-клиенту, который запустил X-сервер и SSH-клиент на HOST1.
Вы все еще здесь? Все это может показаться весьма сложным - ниже приведена диаграмма, которая иллюстрирует, что происходит.
Мы познакомились с основными понятиями X Window-соединений и способами сделать их относительно безопасным. Теперь коротко познакомимся с некоторыми другими программами, работающими в среде X Window.
Xdm - менеджер, который может управлять несколькими X Window-дисплеями на локальной машине или на удаленном сервере. Unix-системы, которые автоматически загружают X Window при запуске, обычно запускают xdm для поддержки X-серверов и сессий. Он запрашивает имя пользователя и пароль, и затем поддерживает рабочую сессию. Xdm поддерживает большинство из упоминавшихся функций аутентификации, генерируя записи в файле Xauthority незаметно для вас при входе в систему.
Xdm использует протокол XDMCP (X Display Manager Control Protocol), который выполняется на UDP-порте с номером 177. Он ожидает запросов от X-серверов, которые запрашивают дисплей менеджер. Это позволяет удаленным X-серверам (особенно X-терминалам, на которых не установлено ничего, кроме X Window) послать запрос хосту, на котором выполняется xdm-менеджер, и который может управлять их X-сессией. Это означает, что машина, на которой выполняется xdm, сообщает другим X серверам - "Вы можете запустить сессию у меня и использовать все мое программное обеспечение и X-клиентов, и отображать у себя результат их работы". Это подобно использованию telnet для входа на машину, за исключением того, что используется
Выполнение XDMCP в сети весьма небезопасно и не рекомендуется, если только вы не работаете в проверенной локальной сети. Если вам нравится возможность входа с использованием X Window на ваш локальный сервер, то это тот случай, когда можно использовать xdm. Но следует убедиться, что вы не прослушиваете XDMCP-запросы и не предоставляете свой xdm-сервис X-серверам, для которых вы этого не предусматривали. Обратитесь к man-страницам за дополнительными деталями настройки системы безопасности xdm.
Xinit инициализирует систему X Window и запускает инициализацию клиентов. Поведение этой программы во многом определяется ее настройками. Обычно она запускается в процессе выполнения скрипта startx. По умолчанию xinit запускает оконную систему (с основными функциями, о которых упоминалось в начале этой лекции) и программы, перечисленные в файле ~/.xinitrc пользователя. В случае его отсутствия просто запускается программа
Xinit можно сконфигурировать так, что будет по умолчанию запускаться ваш любимый оконный менеджер (KDE, Gnome и т.д.). Xinit также позволяет сконфигурировать параметры экрана, цветовой гаммы экрана и тому подобное.
Startx - промежуточное средство, которое позволяет скрыть некоторые сложные детали при запуске и во время выключения X Window. Он обеспечивает поиск различных конфигурационных файлов для клиента и сервера ( xinitrc и xserverrc ) по всем возможным местам их расположения и генерирует командную строку для xinit.
Принимая во внимание, что xdm - это автоматический способ запуска и управления X Window-сессией в процессе загрузки системы, xinit и startx можно считать способом запуска X Window вручную при необходимости.
Xserver - программа, которую xdm запускает, когда кто либо регистрируется в системе, или xinit, когда кто-либо выполняет команду startx. Xserver получает настроечные параметры от программы, которая его запускает. X-сервер обеспечивает сетевые соединения, аутентификацию, управление экраном, управление шрифтами, XDMCP-запросы, и множество других полезных вещей. За подробностями обращайтесь к man-страницам для Xserver.
В этой лекции говорилось об основах архитектуры X Window и были изложены соображения о потенциальной опасности запуска X-приложений. За широкие возможности удаленного запуска графических приложений приходится платить.
Есть несколько X window-утилит, которые могут эксплуатировать эти опасные особенности. Мы упоминали программу /.
Мы отпугнули вас от использования X Window? Не волнуйтесь. Чтобы обеспечить возможную безопасность при запуске X Window вам всего лишь необходимо помнить следующее.
xhost. Это наиболее безопасный подход. Используйте вместо этого xauth.XDMCP, если только вы не работаете в частной сети.Все инструментальные средства, которые мы рассматривали до сих пор, представляли собой утилиты командной строки. Мы запускали их из командной строки, задавая параметры и входную информацию в командной строке, и получали выходную информацию на экран или в файл. Некоторые программисты считают утилиты командной строки сложными и менее функциональными, в то время как другие считают их более эффективными и менее тяжеловесными. В любом случае утилиты командной строки не могут выполнять свою задачу так легко, как бы этого хотелось.
Графические утилиты могут помочь вам визуализировать данные и представить их в удобной для анализа форме. Оконная подсистема Windows является ядром этой операционной системы. Вы не можете установить Windows XP с интерфейсом командной строки, не устанавливая
Эта система понадобится вам для знакомства со следующими программами в этой книге. Ее краткое описание продемонстрирует, как она работает, и как обеспечить ее безопасную работу. Установка и возможности настройки этой системы весьма обширны и в этой книге не обсуждаются, но мы постараемся дать вам общее представление о том, что происходит в X Window. Мы также коснемся нескольких свойственных этой системе проблем с безопасностью, чтобы вы помнили о них.
Простейшая, но важная деталь, касающаяся X Window, состоит в том, что по умолчанию она поставляется без оконного менеджера или рабочего стола. X Window поддерживает клавиатуру, мышь, и окно для вывода информации. Оно поставляется с базовой системой, которая позволяет вам "поместить" окна в любое место на экране и уничтожить эти окна. Причудливые меню и панели инструментов отставлены для оконных менеджеров, которые выполняются поверх X Window. В настоящее время доступно несколько оконных менеджеров, включая такие популярные приложения как Gnome, KDE, и Window Maker. Эмуляторы X Window для системы Window вроде ReflectionX или Exceed также имеют собственные встроенные оконные менеджеры. Важно помнить, что X Window - всего лишь промежуточная архитектура для оконной системы; в ней нет ничего, что бы выглядело, как графическая оконная среда.
X Window использует xemacs, взаимодействие между клиентом и сервером довольно прозрачно. Внешне это выглядит, как если бы это была машина под управлением Microsoft Windows.
Но что, если вы запустите X сервер на машине с именем HOST1, соединитесь с помощью telnet с машиной HOST2, и захотите запустить на HOST2 редактор xemacs? Вам понадобиться указать xemacs-клиенту на HOST2, что необходимо использовать X сервер на машине HOST1. Если вы думаете об этом, то именно в этом состоит глубокий смысл архитектуры клиент/сервер. Обычно, если вы работаете в системе, и вам требуется использование удаленных ресурсов, вы используете локальные клиентские приложения для соединения с удаленным сервером, который предоставляет ресурсы. В случае с X Window, вы запускаете сервер на своей локальной машине, а затем удаленный ресурс (клиент) устанавливает соединение с вами.
Предположим, вы вошли в систему в командной строке (с использованием интерпретатора bash или tcsh ) на HOST2. Вы можете указать системе на HOST2 использовать HOST1 для отображения графических приложений, задав это в командной строке X приложения, которое вы запускаете.
HOST2% xemacs -display HOST1:0.0
Вы можете заставить все X приложения использовать HOST1 по умолчанию для отображения, установив переменную окружения DISPLAY внутри среды командного интерпретатора. Для этого в командной строке HOST2 вы должны выполнить:
HOST2% DISPLAY=HOST1:0.0; export DISPLAY
Для Bourne shell ( sh, bash ), или:
HOST2% setenv DISPLAY HOST1:0.0
для C shell ( tcsh ).
Теперь если вы запустите xemacs, то вместо попыток отображать информацию на HOST2 (на котором может быть запущен X сервер, а может, и нет), он будет пытаться отображать данные на HOST1. Ниже приводятся иллюстрации работы модели клиент/сервер.
Что означает значение :0.0 после строки HOST1 в переменной DISPLAY? Один хост теоретически может выполнять несколько X серверов. Каждый X сервер может управлять несколькими экранами. Формат переменной DISPLAY выглядит следующим образом:
DISPLAY = <hostname>:<displaynumber>.<screennumber>
где:
Если вы не используете необычную конфигурацию X-сервера, значение переменной DISPLAY всегда должно быть равным :0.0. Фактически, вам следует оставить только значение .0, поскольку экран с номером 0 используется по умолчанию.
X-серверы по умолчанию прослушивают TCP-порт с номером 6000. Если на той же самой машине был запущен второй X-сервер (дисплей), он будет прослушивать TCP-порт с номером 6001. Номер дисплея, который будет использовать X-сервер, всегда будет поставлен в соответствие TCP-порту с номером, образованным сложением 6000 с номером дисплея.
Вы можете обратить внимание на небольшую проблему с безопасностью в такой модели клиент/сервер. Задание переменной окружения позволяет нам сообщить клиенту на HOST2 отображать информацию на HOST1. Но что остановит вас от передачи информации от приложения куда ни будь еще? Один из наиболее распространенных способов взлома, рассматриваемых на тренингах по безопасности систем, является определение в переменной DISPLAY параметров вашего собственного X-сервера и наблюдение за тем, как вы запускаете все новые версии программы xeyes на своем рабочем столе всякий раз, когда пытаетесь что-либо сделать. Наиболее пугающим злоупотреблением может быть запуск программы вроде xkey, которая перехватывала бы все вводимые вами символы от X-сервера. Очевидно, что X-сервер должен иметь некоторые способы контроля доступа, чтобы только полномочные клиенты могли выводить свою информацию.
Поскольку X Window взаимодействуют с вашей клавиатурой, мышью и экраном, оставлять X Window незащищенным слишком опасно. Это не только даст возможность кому бы то ни было выводить окна на ваш дисплей, но и кто угодно сможет запустить "невидимое" приложение, которое сможет перехватывать информацию от клавиатуры или от мыши. Вы можете использовать два встроенных метода для блокирования X-сервера - xhost и xauth.
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 - rsh, hosts.allow, hosts.deny и hosts.equiv защитят ваши X-сессии.
xhost + может переопределить все средства обеспечения безопасности, обсуждающиеся в нескольких следующих разделах. Вам следует всячески избегать запуска этих команд без определения имени хоста.Xauth в действительности является не программой контроля доступа, а скорее, графическим интерфейсом пользователя для доступа к файлу Xauthority, который может использоваться X-сервером для обеспечения безопасности. Xauth позволяет добавлять, удалять, просматривать и объединять списки авторизации для доступа к X-серверу. Элементы списка авторизации для доступа к X-серверу содержат имя хоста X-сервера и номер дисплея, протокол авторизации и секретные данные. X-сервер должен при запуске сгенерировать список авторизации на основе своего файла Xauthority (это делает программа xdm ), а клиенты, желающие получить доступ к этому серверу, должны иметь строку авторизации в своем локальном файле Xauthority. X Window-авторизация поддерживает несколько различных протоколов. В этой книге рассматривается только два из них.
xdm (о которой мы кратко поговорим позже). Для обеспечения секретности используется 128-битный ключ, который можно скопировать из Xauthority -файла на сервере в соответствующий файл клиента, используя программу xauth. Когда сервер вызывает клиента, секретный ключ передается в виде простой текстовой строки.xauth, xauth cookies и Xauthority - элементы, являющиеся синонимами.Концепция довольно проста. После запуска X-сервера необходимо сгенерировать запись в файле Xauthority в зависимости от того, какой протокол вы используете. Если вы используете xdm, запись будет сгенерирована автоматически. Многие системы могут автоматически генерировать запись, когда вы вручную запускаете X-сервер. Поговорим о том, как можно сгенерировать Xauthority -запись вручную, чтобы вы представляли себе команды, которые при этом выполняются. Например, будем использовать протокол MIT-MAGIC-COOKIE-1.
На машине, где запущен X-сервер, запустите
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
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), или, что еще хуже, по адресу, принадлежащему другому семейству адресов (например, по DISPLAY (например, в виде 192.168.1.50:0).Передача записей из файла Xauthority от сервера клиенту одинакова независимо от типа используемого протокола авторизации. Некоторые из более продвинутых протоколов включают процедуру SUN-DES-1, которая использует систему Secure RPC от фирмы Sun, и MIT-KERBEROS-5, которая использует аутентификацию пользователей по протоколу Kerberos. Эти методы авторизации более безопасны, но они также и более сложны для первоначальной настройки. За подробной информацией обращайтесь к man-страницам по процедурам xauth, xdm, и по файлу Xsecurity.
Теперь вы можете лучше контролировать доступ к вашему X-серверу, но по прежнему все данные X-сервера передаются по сети открытыми. Несмотря на то, что X-трафик весьма трудно реконструировать (выделить движения мыши и графику среди другой информации), вы можете захотеть добавить шифрование.
Протокол SSH (Secure Shell) дает возможность перенаправить TCP-соединения через SSH-туннель. Если в вашем распоряжении имеется SSH-клиент, который поддерживает перенаправление по протоколу X11, то вы можете зашифровать свои X Window-соединения.
Вновь вернемся к упоминавшемуся ранее примеру с машинами HOST1 и HOST2. Предположим, что мы запустили сервер X Window на машине HOST1, и хотим выполнить клиентское приложение на HOST2 и передавать информацию для отображения на HOST1. Реализация протокола SSH на обеих машинах должна допускать перенаправление X11-трафика (обычно это допускается по умолчанию). Далее следует убедиться, что на SSH сервере на машине HOST2 включена поддержка перенаправления X11 трафика, и для SSH-клиента на машине HOST1 также включена такая поддержка. Вы можете это проверить, просмотрев файлы ssh_config и sshd_config в соответствующей директории (размещающейся в разных местах в зависимости от типа используемой системы, но обычно в директории /etc/ssh ). Проверьте строки X11Forwarding или ForwardX11 и установите параметр "yes", если хотите, чтобы это работало.
ssh_config, можно включить с помощью флага -x. В то же время, перенаправление X11-трафика для SSH-сервера включено по умолчанию, и изменить это можно только в файле sshd_config.С помощью флага -x определим использование перенаправления трафика X11 от HOST1 к HOST2 через SSH. Теперь просмотрим содержимое переменной DISPLAY на HOST2, воспользовавшись командой setenv | grep DISPLAY (для интерпретатора tcsh ) или set | grep DISPLAY (для интерпретатора sh и bash ). Вы должны увидеть нечто похожее на строку
DISPLAY=HOST2:10.0
Но минуточку! Номер дисплея равен 10, а хост - HOST2. Но вы хотели отображать вывод X Window приложения на HOST1. Переменная DISPLAY устанавливается автоматически, как только вы осуществите SSH-соединение с флагом -x. Дисплей номер 10 на HOST2 автоматически назначается на локальный X-сервер, чтобы отображать информацию через SSH на реальном X-сервере на HOST1. Попытайтесь теперь выполнить приложение xclock на HOST2, и вы увидите часики на экране HOST1. Все ваши действия с приложением будут передаваться через шифрованный туннель. Шифрование не строго обязательно, когда вы запускаете удаленно часы, но это может оказаться важным, когда вы используете удаленный запуск редактора xemacs.
-display с любой из команд X Window, если они выполняются через SSH-туннель, поскольку это переопределит специальный "доверенный" сервер, который определяет SSH.Перенаправление X11-трафика через SSH также касается и аутентификации. Вдобавок к автоматическому определению "доверенного" X-сервера, SSH клиент определяет фиктивный идентификационный набор информации и направляет его SSH-серверу. Сервер, в свою очередь, записывает идентификационную информацию в Xauthority файл на удаленной машине, автоматически предоставляя вам доступ к вашему X серверу. Другими словами, если вы запускаете X-сервер на HOST1, SSH-клиент должен сообщить "доверенному" X-серверу на SSH-сервере о необходимости создать следующую запись в Xauthority -файле на HOST2.
HOST2:10 MIT-MAGIC-COOKIE-1 121812483b0b3f19367c1541062b472b
Это предохраняет от передачи реальной идентификационной информации через сеть. В обоих направлениях пересылается только фиктивная идентификационная информация (да и та зашифрованная). Соединения, которые проходят через прокси, могут поставить в соответствие фиктивную идентификационную информацию для HOST2:10 реальным данным для HOST1:0. Это позволяет осуществить перенаправление X-трафика через SSH-туннель к серверу только авторизованному X-клиенту, который запустил X-сервер и SSH-клиент на HOST1.
Вы все еще здесь? Все это может показаться весьма сложным - ниже приведена диаграмма, которая иллюстрирует, что происходит.
Мы познакомились с основными понятиями X Window-соединений и способами сделать их относительно безопасным. Теперь коротко познакомимся с некоторыми другими программами, работающими в среде X Window.
Xdm - менеджер, который может управлять несколькими X Window-дисплеями на локальной машине или на удаленном сервере. Unix-системы, которые автоматически загружают X Window при запуске, обычно запускают xdm для поддержки X-серверов и сессий. Он запрашивает имя пользователя и пароль, и затем поддерживает рабочую сессию. Xdm поддерживает большинство из упоминавшихся функций аутентификации, генерируя записи в файле Xauthority незаметно для вас при входе в систему.
Xdm использует протокол XDMCP (X Display Manager Control Protocol), который выполняется на UDP-порте с номером 177. Он ожидает запросов от X-серверов, которые запрашивают дисплей менеджер. Это позволяет удаленным X-серверам (особенно X-терминалам, на которых не установлено ничего, кроме X Window) послать запрос хосту, на котором выполняется xdm-менеджер, и который может управлять их X-сессией. Это означает, что машина, на которой выполняется xdm, сообщает другим X серверам - "Вы можете запустить сессию у меня и использовать все мое программное обеспечение и X-клиентов, и отображать у себя результат их работы". Это подобно использованию telnet для входа на машину, за исключением того, что используется
Выполнение XDMCP в сети весьма небезопасно и не рекомендуется, если только вы не работаете в проверенной локальной сети. Если вам нравится возможность входа с использованием X Window на ваш локальный сервер, то это тот случай, когда можно использовать xdm. Но следует убедиться, что вы не прослушиваете XDMCP-запросы и не предоставляете свой xdm-сервис X-серверам, для которых вы этого не предусматривали. Обратитесь к man-страницам за дополнительными деталями настройки системы безопасности xdm.
Xinit инициализирует систему X Window и запускает инициализацию клиентов. Поведение этой программы во многом определяется ее настройками. Обычно она запускается в процессе выполнения скрипта startx. По умолчанию xinit запускает оконную систему (с основными функциями, о которых упоминалось в начале этой лекции) и программы, перечисленные в файле ~/.xinitrc пользователя. В случае его отсутствия просто запускается программа
Xinit можно сконфигурировать так, что будет по умолчанию запускаться ваш любимый оконный менеджер (KDE, Gnome и т.д.). Xinit также позволяет сконфигурировать параметры экрана, цветовой гаммы экрана и тому подобное.
Startx - промежуточное средство, которое позволяет скрыть некоторые сложные детали при запуске и во время выключения X Window. Он обеспечивает поиск различных конфигурационных файлов для клиента и сервера ( xinitrc и xserverrc ) по всем возможным местам их расположения и генерирует командную строку для xinit.
Принимая во внимание, что xdm - это автоматический способ запуска и управления X Window-сессией в процессе загрузки системы, xinit и startx можно считать способом запуска X Window вручную при необходимости.
Xserver - программа, которую xdm запускает, когда кто либо регистрируется в системе, или xinit, когда кто-либо выполняет команду startx. Xserver получает настроечные параметры от программы, которая его запускает. X-сервер обеспечивает сетевые соединения, аутентификацию, управление экраном, управление шрифтами, XDMCP-запросы, и множество других полезных вещей. За подробностями обращайтесь к man-страницам для Xserver.
В этой лекции говорилось об основах архитектуры X Window и были изложены соображения о потенциальной опасности запуска X-приложений. За широкие возможности удаленного запуска графических приложений приходится платить.
Есть несколько X window-утилит, которые могут эксплуатировать эти опасные особенности. Мы упоминали программу /.
Мы отпугнули вас от использования X Window? Не волнуйтесь. Чтобы обеспечить возможную безопасность при запуске X Window вам всего лишь необходимо помнить следующее.
xhost. Это наиболее безопасный подход. Используйте вместо этого xauth.XDMCP, если только вы не работаете в частной сети.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.