PAM

Resources

Home

Wikipedia

Project

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

Введение

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

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

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

Заметка
PAM не предоставляет никаких сервисов для авторизации. Обычно авторизация выполняется внутри приложения. Некоторые приложения поддерживают авторизацию на основе принадлежности группе (члену группы разрешается авторизация). Распространённым подходом (но не для PAM) для этого является поддержка NSS (Name Service Switch). NSS по своей архитектуре очень похож на PAM. Фактически, на серверах Linux авторизация управляется с помощью библиотек NSS.

Принципы работы PAM

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

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

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

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

Как работает PAM

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

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

Конфигурация

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

Файл /etc/pam.d/someserviceПример конфигурационного файла PAM для сервиса с названием "someservice"

# Аутентификация
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

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

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

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

PAM и Gentoo

Для приложений, поддерживающий PAM, принудительно включён USE-флаг pam. Хотя и возможно создать систему Gentoo без поддержки PAM (USE="-pam"), но по умолчанию поддержка PAM включена.

Смотрите также

• PAM (Security Handbook)
• Статья Модуль pam_ssh_agent, описывающая установку и конфигурацию стороннего модуля PAM, который организовывает аутентификацию через инфраструктуру открытых ключей SSH
• Статья Google Authenticator, описывающая установку и использование приложения аутентификатора Google для аутентификации через PAM

Внешние ресурсы

• Working with PAM, раздел руководства разработчика Gentoo