Подключаемые модули аутентификации (PAM). Общие сведения

PAM (Pluggable Authentication Modules) — это модульный подход к системе аутентификации. Они позволяют сторонним службам предоставлять модуль аутентификации для обеспечения доступа к службе для систем с поддержкой PAM. Службы, использующие PAM для аутентификации, могут использовать их сразу же, без необходимости дополнительной пересборки.

На сервере Linux PAM могут использоваться для управления аутентификацией (как часть управления предоставления доступа). При использовании PAM сервисам нет необходимости поддерживать собственную систему аутентификации. Вместо этого они полагаются на модули PAM, доступные в системе. Любой сервис при необходимости может использовать собственную конфигурацию PAM, хотя в большинстве случаев аутентификация выполняется одинаково во множестве сервисов. Вызывая модули PAM, сервисы могут поддерживать двухфакторную аутентификацию «из коробки», сразу же использовать централизованные хранилища аутентификационных средств и многое другое.

PAM предоставляют гибкую модульную архитектуру для следующих сервисов:

• Управление аутентификацией — проверяет, существует ли пользователь, под которым пытаются зайти.
• Управление учётными записями — проверяет, что пароль пользователя не истёк или имеет ли пользователь право обращаться к определённому сервису.
• Управление сеансами — выполняет определённые задачи во время входа или выхода пользователя из системы (аудит, монтирование файловых систем и так далее).
• Управление паролями — предлагает интерфейс для сброса пароля и тому подобное.

При работе с PAM администраторы очень быстро поймут принципы, по которым функционирует PAM.

Во-первых, это «независимость от бэкенда». Приложениям, поддерживающим PAM, нет необходимости учитывать низкоуровневую логику, чтобы работать с бэкендами, например, базами данных, службой LDAP, файлами паролей, веб-службами с поддержкой WS-Security или другими бэкендами. Используя PAM, приложения отделяют логику работы бэкенда от своей. Всё, что им нужно сделать — это вызвать функцию PAM.

Другим принципом является «независимость от конфигурации». Администраторам не нужно знать, как настраивать десятки различных приложений, чтобы заставить их поддерживать аутентификацию через LDAP-сервер. Вместо этого им достаточно воспользоваться одной конфигурационной структурой, предоставляемой PAM.

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

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

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

Другой важной особенностью PAM является то, что они поддерживают объединение в цепочки нескольких модулей. Пример конфигурационного файла для сервиса:

# Аутентификация
auth required pam_env.so
auth required pam_ldap.so

# Управление учётными записями
account required pam_ldap.so

# Управление паролями
password required pam_ldap.so

# Управление сеансами
session optional pam_loginuid.so
session required pam_selinux.so close
session required pam_env.so
session required pam_log.so level=audit
session required pam_selinux.so open multiple
session optional pam_mail.so

Видно, что конфигурационный файл разделён на четыре области сервисов, которые поддерживают PAM: аутентификация, управление учётными записями, управление паролями и управление сеансами.

Каждый из этих разделов в файле вызывает один или несколько модулей PAM. Например, pam_env.so устанавливает переменные среды, которые могут быть использованы последующими модулями. Код, возвращаемый модулем PAM, вместе с управляющими директивами (в данном примере — required или optional) позволяет PAM решать, что делать дальше.

PAM поддерживают следующие управляющие директивы:

• required — указанный модуль PAM должен вернуть код успеха для того, чтобы весь сервис (например, аутентификация) был успешен. Если модуль PAM вернёт код неудачи, остальные модули будут всё равно вызваны (хотя уже точно известно, что сам сервис будет недоступен).
• requisite — указанный модуль PAM должен вернуть код успеха для того, чтобы весь сервис был доступен. В отличие от required, если модуль PAM вернёт код неудачи, директива сразу же завершится, и сам сервис будет недоступен.
• sufficient — если указанный модуль PAM вернёт код успеха, весь сервис будет разрешен. Оставшиеся модули PAM не будут проверяться. Однако, если модуль PAM вернёт код неудачи, оставшиеся модули пройдут проверку, а неудача данного модуля не будет приниматься во внимание.
• optional — код успеха или неудачи указанного модуля PAM будет иметь значение, если это единственный модуль в стеке.

Цепочки модулей позволяют выполнить множественную аутентификацию, выполнить несколько задач в процессе создания сеанса и тому подобное.

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

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

Это же относится к тому месту, где располагаются модули PAM (/lib/security или /lib64/security).

Помимо файлов-сценариев для некоторых модулей могут использоваться дополнительные файлы конфигурации. Все они расположены в каталоге /etc/security и каждый файл предназначен для конкретной группы настроек.

• time.conf — здесь вы сможете ограничить время доступа пользователей с различных терминалов к различным сервисам. Например, запретить входить в систему с первой виртуальной консоли администратору во время выходных. Эти настройки обслуживает модуль pam_time и, соответственно, если вы желаете, чтобы ваши ограничения возымели действие модуль должен быть прописан в соответствующем сценарии.
• pam_env.conf — здесь можно ограничить возможности в изменении отдельных переменных среды пользователями. Работает под руководством модуля pam_env.
• limits.conf — здесь можно индивидуально или для группы ограничить: размер core-файла, максимальный допустимый размер файла, максимальное количество открытых файлов, запущенных процессов, сколько раз можно одновременно зайти в систему и т.д. Руководящий модуль pam_limits.
• access.conf — играет важную роль, поскольку PAM предоставляет средства аутентификации по сети. Подобные настройки оказываются полезными, поскольку контролируется не только, кто может войти, но и откуда. Для осуществления такого контроля используется pam_access.
• group.conf — можно указать какой группе будет принадлежать служба запущенная определенным пользователем в определенное время с определенного терминала. Контролируется pam_time и pam_group.
• console.perms — несколько выбивается своим названием, но не функциями. Здесь определяются права, получаемые привилегированными пользователями к консоли во время входа в систему и возвращаемые при выходе. Модуль pam_console.

Список модулей:

• pam_cracklib: тип password. Проверяет ваш пароль на стойкость, не является ли он, например, палиндромом (примечание — это не обязательно при использовании модуля pam_unix). Полезен для программ, задающих пароли. Полезные параметры:
  retry=N — дается N попыток на исправление ошибки,
  diffok=N — должно быть изменено минимум N символов при смене пароля,
  minlen=N — минимальный размер пароля,
  dcredit=N ucredit=N lcredit=N ocredit=N — в пароле должно присутствовать минимум N цифр, строчных, прописных букв и других символов.
• pam_deny: Тип любой. Всегда перекрывает доступ.
• pam_env: Тип auth. Контролирует сохранность переменных среды. Полезный параметр conffile=S - задает альтернативное название файла конфигурации.
• pam_ftp: Тип auth. Предназначен для организации анонимного доступа. То есть, получив имя пользователя «anonymous», ждет в качестве пароля что-то похожее на его почтовый адрес. Полезные параметры:
  ignore — не обращать внимание похож ли пароль на почтовый адрес,
  users=XXX,YYY — позволяет анонимный вход для пользователей из этого списка.
• pam_group: Тип auth. Предназначение ясно из описания конфигурационного файла group.conf.
• pam_lastlog: Тип session. Сообщает о времени и месте входа в систему. Обновляет /var/log/wtmp файл. Полезные параметры:
  nodate, noterm, nohost, silent — не выводить в сообщении даты, терминала, машины или вообще ничего,
  never — если пользователь никогда ранее не появлялся, то его приветствуют.
• pam_limits: Тип session. Предназначение указано выше при описании файла limits.conf. Полезный параметр:
  conf=S — альтернативное имя конфигурационного файла.
• pam_listfile: Тип auth. Предназначен для организации доступа на основе конфигурационных файлов-списков например /etc/ftpaccess. Для примера смотрите соответствующие файлы сценариев. Возможные параметры: on err=succeed|fail; sence=allow|deny; file=filename; item=user|tty|rhost|ruser|group|shell apply=user|@group. Первый параметр задает возвращаемое значение в случае неудачного поиска. Второй — в случае удачного поиска. Третий — имя файла со списком. Четвертый — тип элемента в списке. Последний вносит дополнительные ограничения, если тип объявлен tty, rhost или shell.
• pam_mail: Тип auth. Сообщается о наличии почты, если таковая имеется. Полезные параметры:
  dir=S — путь к каталогу почтовых очередей,
  noenv — не устанавливать переменную среды MAIL,
  close — сообщать, если есть почта у пользователей с аннулированными бюджетами,
  nopen — не печатать какой-либо почтовой информации, если пользовательский бюджет только что заведен.
• pam_nologin: Тип auth. Стандартная реакция на наличие файла /etc/nologin. Когда он присутствует, в систему может зайти только root, а остальным будет выдано на экран содержимое этого файла.
• pam_permit: Тип любой. Использование данного модуля ОПАСНО и применимо только в критических ситуациях. Всегда дает допуск.
• pam_pwdb: Тип любой. Замещает модули серии pam_unix... . Использует интерфейс библиотеки libpwdb (пользовательские базы данных), что повышает независимость системы аутентификации от способа хранения пользовательских данных (NIS или passwd или shadow). Полезные параметры:
  nullok — можно использовать пустые пароли,
  md5, shadow, bigcrypt — различные способы шифрования пароля.
• pam_radius: Тип session. Позволяет осуществлять аутентификацию через RADIUS сервер.
• pam_rhosts_auth: Тип auth. Механизм работы этого модуля основывается на анализе содержимого файлов hosts.equiv и .rhosts, используемых для аутентификации таких служб как rlogin и rsh. Полезные параметры:
  no_hosts_equiv — игнорировать содержимое файла hosts.equiv,
  no_rhosts — игнорировать содержимое файлов .rhosts,
  suppres s — охраняет системные журналы от потока малозначимых сообщений, в частности когда используется контрольный флаг sufficient.
• pam_rootok: Тип auth. Используется в случае, когда администратору необходимо получать доступ к сервису без введения пароля. Этот модуль допускает пользователя к сервису, только если его uid равен 0.
• pam_securetty: Включает в проверку файл /etc/securitty. Суперпользователь сможет зайти только на указанных там терминалах.
• pam_time: Тип account. Смотри описание устройства конфигурационного файла time.conf.
• pam_warn: Тип auth, session и password. Просто ведет записи в системных журналах, например, при смене пароля.
• pam_wheel: Тип auth и account. Права суперпользователя может использовать только пользователь группы wheel (группа root в Linux). Полезные параметры:
  group=XXX — использовать указанную группу вместо стандартной нулевой,
  deny — инвертирование действия алгоритма, запрещается получать права суперпользователя пользователям указанной группы, используется вместе с предыдущим параметром,
  trust — избавляет пользователей группы wheel от необходимости вводить пароль при смене uid на 0.

Дата последнего изменения: 07.02.2025

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.