Безопасность

В целях безопасности, рекомендуется использовать выделенную учётную запись пользователя и группы. В большинстве систем это — «gdm». Но GDM можно настроить на использование любой другой учётной записи. Все графические программы GDM запускаются от имени этой учётной записи и взаимодействие происходит в рамках её прав. Поэтому желательно ограничить права пользователя и группы gdm.

Единственная специальная привелегия учётной записи «gdm», необходимая для работы — это возможность чтения и записи файлов Xauth в каталог <var>/run/gdm, который должен иметь владельца root:gdm и права доступа 1777.

Ни при каких обстоятельствах не следеут указывать GDM такую учётную запись, к которой пользователь может легко получить доступ, например nobody. Любой пользователь, который получит доступ к ключу Xauth, сможет проследить или перехватить контроль над соответствующими работающими графическими приложениями или организовать DoS атаку на текущий сеанс. Важно убедиться, что система настроена таким образом, что только учётная запись «gdm» имеет доступ к этим файлам, и что войти в систему под этой учётной записью невозможно. Например, такая учётная запись не должна иметь пароля или позволять обычным пользователям входить под этой учётной записью.

Конфигурация программы приветствия GDM хранится в GConf. Чтобы разрешить GDM записывать конфигурацию, необходимо учётной записи «gdm» дать права записи в свой домашний каталог $HOME. Пользователи могут самостоятельно изменять конфигурацию по умолчанию в GConf, чтобы избежать необходимости обечпечивать учётной записи «gdm» права записи в домашний каталог $HOME. При этом некоторые возможности GDM могут быть недоступны, если у него нет возможности записывать информацию в конфигурацию GConf.

GDM использует модуль PAM для аутентификации при входе в систему. PAM означает: подключаемый модуль аутентификации (Pluggable Authentication Module), и используется большинством программ, требующим аутентификацию пользователя. Это позволяет администратору настроить способы аутентификации для разных программ входа в систему (например: ssh, login, хранителей экрана и так далее).

PAM является достаточно сложным модулем со множеством параметров конфигурации, поэтому в этом документе не представлены детали его настройки, а лишь даётся необходимая информация по настройке PAM для работы с GDM. Предполагается, что читатель, желающий настроить PAM, знаком с его документацией и понимает принципы конфигурирования PAM, а также термины, используемые в этом разделе.

На разных операционных системах PAM имеет различные, но похожие интерфейсы конфигурирования, поэтому обратитесь к страницам руководства pam.d или pam.conf для подробной информации. Необходимо ознакомиться с документацией PAM и возможным влиянием на безопасность тех изменений, которые вы собираетесь внести в конфигурацию.

По умолчанию GDM использует сервисы PAM с именем «gdm» для обычного входа и «gdm-autologin» для автоматического входа. Если эти сервисы не определены в конфигурационных файлах «pam.d» или «pam.conf», то GDM будет использовать обычное поведение PAM. На большинстве систем это сработает, но автоматический вход в систему может не работать, если не определен сервис PAM «gdm-autologin».

Сценарий PostLogin выполняется перед вызовом метода pam_open_session, а сценарий PreSession после, что позволяет системному администратору добавить любые сценарии до или после того, как PAM инициализирует сеанс.

Если вы хотите использовать с GDM другие типы аутентификации (например, сканирование отпечатков пальцев или карты SmartCard), то это реализовывается с помощью соответствующих сервисных модулей PAM, а не изменением кода GDM. За дополнительной информацией обращайтесь к документации PAM. То как использовать такие механизмы часто обсуждается в списке рассылки

PAM имеет некоторые ограничения при работе с несколькими типами аутентификации одновременно, например возможность одновременного использования карт SmartCard и аутентификации путем ввода имени пользователя и пароля. Есть способы использования такой возможности, и лучший способ их изучить — это установить конфигурацию с такими настройками.

Если не работает автоматический вход в систему проверьте наличие сервиса «gdm-autologin» в конфигурации PAM. Для включения этой возможности необходимо использовать модуль PAM, который не производит аутентификации или возвращает PAM_SUCCESS со всех интерфейсов, например модуль pam_allow.so, с использованием которого конфигурация PAM с включённым сервисом «gdm-autologin» будет выглядеть следующим образом:

       gdm-autologin auth  required    pam_unix_cred.so.1
       gdm-autologin auth  sufficient  pam_allow.so.1
       gdm-autologin account  sufficient  pam_allow.so.1
       gdm-autologin session  sufficient  pam_allow.so.1
       gdm-autologin password  sufficient  pam_allow.so.1

Указанная настройка не будет генерировать записи lastlog. Если они необходимы, то используйте следующее для сеанса:

       gdm-autologin сеанс требует  pam_unix_session.so.1

Если компьютером пользуются несколько человек, то автоматический вход в систему нежелателен. Пользователи могут входить в систему, не вводя пароль. Эта возможность настраивается отдельно для каждого пользователя; для этого нужно, чтобы пользователь был членом группы «nopasswdlogin», а конфигурационный файл PAM содержал следующую строку:

      gdm auth  sufficient  pam_succeed_if.so  user ingroup nopasswdlogin

GDM создает записи в базах данных utmp и wtmp учёта пользователей во время входа и выхода пользователей из системы. База данных utmp содержит информацию о пользователе и его правах доступа, которая доступна с помощью команд: finger, last, login и who. База данных wtmp содержит историю базы utmp. Для получения дополнительной информации обратитесь к страницам man utmp и wtmp.

Файлы аутентификации X сервера находятся во вновь создаваемом во время запуска подкаталоге в <var>/run/gdm>. Эти файлы содержат ключ доступа для X клиента и сервера, который уникален для каждого сеанса, поэтому пользователи из разных сеансов не мешают друг другу.

GDM поддерживает только схему аутентификации X сервера «MIT-MAGIC-COOKIE-1». Другие схемы не обладают значительными преимуществами и на настоящий момент не являются приоритетными. Следует быть особенно осторожным при использовании протокола XDMCP, так как аутентификационная информация (в виде cookies) передается по сети в открытом виде, поэтому она доступна для перехвата. В этом случае злоумышленник может просто перехватить ключ при входе в систему. Для предотвращения этого необходимо использовать туннелирование X соединений через ssh, вместо протокола XDMCP. Протокол XDMCP не достаточно безопасен, чтобы его использовать как протокол удалённого графического терминала, в большинстве случаев лучше использовать «ssh -Y» вместо возможностей GDM по работе с XDMCP.

Не смотря на то, что дисплей защищен аутентификационной информацией (в cookies), события XEvents и соответствующие нажатия клавиш при вводе пароля будут переданы по сети в открытом виде и их легко перехватить.

XDMCP в основном предназначен для использования в лабораторных терминалах, где клиентам необходима сеть лишь для соединения с сервером. Лучшей политикой безопасности будет использование таких клиентов в отдельной подсети к которой нет доступа извне, и единственной точкой доступа во внешние сети является сам сервер. Подобные конфигурации нельзя использовать в сетях с неуправляемыми концентраторами или прослушиваемых сетях.

Контроль доступа XDMCP реализован с использованием библиотеки TCP Wrappers. В некоторых операционных системах GDM собран без поддержки TCP Wrappers, поэтому подобные возможности могут быть недоступны.

Необходимо использовать имя демона gdm в файлах <etc>/hosts.allow и <etc>/hosts.deny. Например, чтобы запретить машинам из домена .evil.domain входить в систему, необходимо добавить следующее:

gdm: .evil.domain

в файл <etc>/hosts.deny. Возможно, также необходимо добавить

gdm: .your.domain

в файл <etc>/hosts.allow, если по умолчанию запрещены все сервисы со всех машин. За деталями обратитесь к станицам man hosts.allow(5).

Хотя GDM и пытается предупредить возможные атаки на протокол XDMCP, рекомендуется заблокировать порт XDMCP (обычно UDP 177) на сетевом экране до тех пор, пока он действительно не понадобится. GDM пытается предотвратить DoS атаки, но X протокол традиционно небезопасен и его следует использовать только в безопасных средах. Кроме того, каждое удалённое соединение потребляет относительно много ресурсов, поэтому организовать DoS атаку через XDMCP намного проще, чем на веб-сервер.

Также рекомендуем заблокировать все порты, используемые X-сервером (все TCP-порты, начиная с 6000; один для каждого номера дисплея). GDM использует номера дисплеев больше 20 для гибких серверов-по-требованию.

X — не очень безопасный протокол при использовании его через интернет, но XDMCP еще менее безопасен.

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

Видимость этих кнопок регулируется действиями:org.freedesktop.consolekit.system.stop-multiple-users и org.freedesktop.consolekit.system.restart-multiple-users соответственно. Политика этих действий может быть установлена с помощью утилиты polkit-gnome-authorization или консольной программой polkit-auth.

GDM можно настроить на использование RBAC вместо PolicyKit. В этом случае используется конфигурация RBAC для управления видимостью кнопок выключения и перезагрузки системы на экране программы приветствия.

Например, в системе Oracle Solaris для этого используется авторизация «solaris.system.shutdown». Достаточно изменить файл /etc/user_attr так, чтобы учётная запись «gdm» осуществляла эту авторизацию.