Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
В X Window System программы выполняются как X-клиенты и, следовательно, подключаются к X-серверу отображения, возможно, через компьютерную сеть. Поскольку к сети могут иметь доступ другие пользователи, необходим механизм запрета доступа к программам, запущенным пользователями, отличными от вошедшего в систему. Существует пять стандартных механизмов контроля доступа, определяющих, может ли клиентское приложение подключиться к X-серверу отображения. Их можно сгруппировать в три категории: доступ на основе хоста, доступ на основе cookie и доступ на основе пользователя. Кроме того, как и любое другое сетевое соединение, может использоваться туннелирование.
In the X Window System, programs run as X clients, and as such they connect to the X display server, possibly via a computer network. Since the network may be accessible to other users, a method for forbidding access to programs run by users different from the one who is logged in is necessary. There are five standard access control mechanisms that control whether a client application can connect to an X display server. They can be grouped in three categories:
access based on host
access based on cookie
access based on user
Additionally, like every other network connection, tunneling can be used.
Доступ на основе хоста
Метод доступа на основе хоста заключается в указании набора хостов, которым разрешено подключаться к X-серверу. Эта система обладает более низкой степенью безопасности, поскольку позволяет любому пользователю, имеющему доступ к такому хосту, подключаться к дисплею. Для активации этого механизма, а также для просмотра и изменения списка авторизованных хостов используются программа xhost и три базовых запроса протокола X Window System. Неправильное использование xhost может непреднамеренно предоставить всем хостам в Интернете полный доступ к X-серверу.
The host based access method consists in specifying a set of hosts that are authorized to connect to the X display server. This system has inferior security, as it allows every user who has access to such a host to connect to the display. The xhost program and three X Window System core protocol requests are used to activate this mechanism and to display and change the list of authorized hosts. Improper use of xhost can inadvertently give every host on the Internet full access to an X display server.
Доступ на основе файлов cookie
Методы авторизации на основе cookie основаны на выборе "волшебного cookie" (произвольного фрагмента данных) и передаче его серверу X при запуске; каждый клиент, способный подтвердить знание этого cookie, затем авторизуется для подключения к серверу. Эти cookie создаются отдельной программой и по умолчанию хранятся в файле Xauthority в домашней директории пользователя. В результате, любая программа, запущенная клиентом на локальном компьютере, может получить доступ к этому файлу и, следовательно, к cookie, необходимому для авторизации сервером. Если пользователь хочет запустить программу с другого компьютера в сети, cookie необходимо скопировать на этот компьютер. Способ копирования cookie зависит от системы: например, на Unix-подобных платформах можно использовать scp для копирования cookie. Две системы, использующие этот метод, – MIT MAGIC COOKIE 1 и XDM AUTHORIZATION 1. В первом методе клиент просто отправляет cookie по запросу для аутентификации. Во втором методе секретный ключ также хранится в файле Xauthority. Клиент создает строку, объединяя текущее время, идентификатор, зависящий от транспортного протокола, и cookie, шифрует полученную строку и отправляет ее на сервер. Утилита xauth предназначена для доступа к файлу Xauthority. Переменная окружения XAUTHORITY может быть определена для изменения имени и расположения этого файла cookie. Протокол Inter Client Exchange (ICE), реализованный библиотекой Inter Client Exchange Library для прямого взаимодействия между клиентами X11, использует тот же метод аутентификации MIT MAGIC COOKIE 1, но имеет собственную утилиту iceauth для доступа к файлу ICEauthority, расположение которого можно изменить с помощью переменной окружения ICEAUTHORITY. ICE используется, например, DCOP и протоколом управления сеансом X (XSMP).
The cookie based authorization methods are based on choosing a magic cookie (an arbitrary piece of data) and passing it to the X display server when it is started; every client that can prove having knowledge of this cookie is then authorized connecting to the server. These cookies are created by a separate program and stored in the file Xauthority in the user's home directory, by default. As a result, every program run by the client on the local computer can access this file and therefore the cookie that is necessary for being authorized by the server. If the user wants to run a program from another computer on the network, the cookie has to be copied to that other computer. How the cookie is copied is a system dependent issue: for example, on Unix like platforms, scp can be used to copy the cookie. The two systems using this method are MIT MAGIC COOKIE 1 and XDM AUTHORIZATION 1. In the first method, the client simply sends the cookie when requested to authenticate. In the second method, a secret key is also stored in the Xauthority file. The client creates a string by concatenating the current time, a transport dependent identifier, and the cookie, encrypts the resulting string, and sends it to the server. The xauth application is a utility for accessing the Xauthority file. The environment variable XAUTHORITY can be defined to override the name and location of that cookie file. The Inter Client Exchange (ICE) Protocol implemented by the Inter Client Exchange Library for direct communication between X11 clients uses the same MIT MAGIC COOKIE 1 authentication method, but has its own iceauth utility for accessing its own ICEauthority file, the location of which can be overridden with the environment variable ICEAUTHORITY. ICE is used, for example, by DCOP and the X Session Management protocol (XSMP).
Пользовательский доступ
Методы доступа на основе пользователей работают, авторизуя конкретных пользователей для подключения к серверу. Когда клиент устанавливает соединение с сервером, он должен подтвердить, что управляется авторизованным пользователем. Два метода, основанные на аутентификации пользователей с использованием сетевых систем управления идентификацией, – это SUN DES 1 и MIT KERBEROS 5. Первая система основана на защищенном механизме удаленных процедурных вызовов ONC, разработанном в SunOS. Второй механизм основан на доверии клиента и сервера к серверу Kerberos. Третий метод ограничен локальными соединениями и использует системные вызовы для определения пользователя, находящегося на другом конце локального сокета. Программа xhost может использоваться для добавления или удаления записей localuser и localgroup при использовании этого метода.
The user based access methods work by authorizing specific users to connect to the server. When a client establishes a connection to a server, it has to prove being controlled by an authorized user. The two methods based on authenticating users using networked identity management systems are SUN DES 1 and MIT KERBEROS 5. The first system is based on a secure mechanism of the ONC remote procedure call system developed in SunOS. The second mechanism is based on both client and server trusting a Kerberos server. A third method is limited to local connections, using system calls to ask the kernel what user is on the other end of a local socket. The xhost program can be used to add or remove localuser and localgroup entries with this method.
Прокладка туннелей
Утилита SSH (при вызове с опцией X или опцией ForwardX11) создает туннель для X11-трафика от удаленных клиентов к локальному серверу. Это достигается путем установки на удаленной машине переменной окружения DISPLAY, указывающей на локальный TCP-сокет, открытый там демоном sshd, который затем перенаправляет X11-коммуникацию обратно в SSH. Демон sshd также вызывает xauth для добавления на удаленной машине строки MIT MAGIC COOKIE 1 в файл Xauthority, что авторизует X11-клиенты на удаленной машине для доступа к локальному X-серверу пользователя SSH. X11-соединения между клиентом и сервером по сети также могут быть защищены другими протоколами безопасного канала, такими как Kerberos/GSSAPI или TLS, хотя эти варианты сейчас используются значительно реже, чем SSH.
The SSH utility (when invoked with option X or option ForwardX11) tunnels X11 traffic from remotely invoked clients to the local server. It does so by setting at the remote site the DISPLAY environment variable to point to a local TCP socket opened there by sshd, which then tunnels the X11 communication back to ssh. Sshd then also calls xauth to add at the remote site an MIT MAGIC COOKIE 1 string into Xauthority there, which then authorizes X11 clients there to access the ssh user's local X server. X11 connections between client and server over a network can also be protected using other secure channel protocols, such as Kerberos/GSSAPI or TLS, although such options are now far more rarely used than SSH.