Pluggable Authentication Modules

PAM была предложена^[2] компанией Sun Microsystems для решения проблемы аутентификации, поставленной в 1995 году группой security group, участвовавшей в разработке графической среды Common Desktop Environment в рамках Open Software Foundation. Решение PAM было выбрано в июне и затем описано в октябре 1995 года в RFC под эгидой Open Software Foundation и была представлена на конференции ACM в 1996 году^[2].

Хотя идея принадлежит инженерам Sun Microsystems, первая реализация была выполнена в январе 1996 года Марком Юингом (Marc Ewing) из Red Hat в проекте Linux-PAM^[3].

После этого PAM была портирована на разные архитектуры, в том числе Solaris, Linux, FreeBSD^[4], NetBSD, DragonFly BSD^[5], AIX^[6] и HP-UX.

Архитектура Pluggable Authentication Modules (PAM) является модульной и многоуровневой, что обеспечивает гибкость в настройке политик аутентификации и отделяет приложения от конкретных методов проверки подлинности. Она состоит из четырёх ключевых уровней:^[7]

• Приложения (Application Layer) — программы, требующие аутентификации (например, login, sshd или sudo). Они вызывают функции из библиотеки PAM, не вдаваясь в детали реализации процесса проверки подлинности^[7].
• Библиотека PAM (API Layer) — ядро системы (обычно библиотека libpam), предоставляющее единый интерфейс программирования приложений. Она считывает конфигурационные файлы и последовательно вызывает необходимые модули^[8].
• Конфигурационные файлы (Configuration Layer) — уровень, определяющий политики аутентификации для каждого отдельного сервиса. Конфигурация обычно располагается в каталоге /etc/pam.d/, где описываются цепочки модулей для различных задач^[9].
• Модули PAM (SPI Layer) — набор разделяемых библиотек (например, pam_unix.so, pam_ldap.so), выполняющих конкретные задачи. Каждый модуль реализует одну или несколько групп управления: аутентификация (auth), управление учётными записями (account), управление сессиями (session) и управление паролями (password)^[10].

В современных Unix-подобных операционных системах конфигурация PAM преимущественно осуществляется через каталог /etc/pam.d/, где для каждой службы создаётся отдельный конфигурационный файл. Этот подход пришёл на смену устаревшему методу, использовавшему единый конфигурационный файл /etc/pam.conf для всех служб^[11].^[12]

Каждая строка в конфигурационном файле определяет вызов одного модуля и имеет следующий синтаксис: тип_модуля управляющий_флаг путь_к_модулю [аргументы]^[13][14]

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

• required — для общего успеха стека модуль должен успешно завершить работу. Если модуль завершается с ошибкой, PAM запоминает этот результат, но продолжает выполнение остальных модулей в стеке. Итоговый результат будет отрицательным^[15].^[11]
• requisite — модуль должен завершиться успешно. В отличие от required, в случае сбоя обработка стека немедленно прекращается, и приложению сразу же возвращается ошибка^[15].^[11]
• sufficient — если модуль завершается успешно и ни один из предыдущих модулей required не завершился с ошибкой, аутентификация считается успешной, а все последующие модули в стеке игнорируются. Сбой этого модуля игнорируется^[15].^[11]
• optional — успех или сбой модуля игнорируется. Его результат имеет значение только в том случае, если ни один другой модуль в стеке не определил итоговый результат^[15].^[11]

Модули PAM представляют собой расширяемый набор динамических библиотек, например, pam_unix.so, которые предоставляют шесть операций аутентификации, определённых стандартом, сгруппированных в четыре механизма:

• Механизм account предоставляет одну функцию: проверяет, доступна ли учётная запись (например, не истёк ли срок её действия, разрешено ли пользователю входить в данное время суток и т. д.).
• Механизм auth предоставляет две функции: выполняет непосредственную аутентификацию (например, запрашивает и проверяет пароль), а также определяет «идентификационные сертификаты» вроде членства в группах или «тикеты» Kerberos.

В современных системах для реализации двухфакторной и многофакторной аутентификации (2FA/MFA) применяются такие модули, как pam_google_authenticator (для одноразовых паролей TOTP/HOTP) и pam_u2f (для аппаратных ключей стандарта FIDO2/U2F)^[16][17].

• Механизм password предоставляет одну функцию: позволяет обновлять аутентификационный токен (чаще всего — пароль), как по истечении срока его действия, так и по желанию пользователя.
• Механизм session включает две функции: инициализацию и завершение пользовательской сессии. Он активируется после успешной аутентификации и позволяет пользователю использовать учётную запись, предоставляя доступ к отдельным ресурсам, например, монтируя домашний каталог, открывая почтовый ящик, запуская агент ssh и пр.

Примером современного модуля управления сессиями является pam_systemd, который интегрирует сеансы с systemd, регистрируя их в systemd-logind, создавая пользовательский каталог времени выполнения и управляя юнитами^[18].

• pam_mount — расширение PAM, позволяющее монтировать файловую систему при подключении пользователя. Например, может быть произведён автоматический монтирование каталога CIFS с использованием только что введённого пользователем пароля, после чего раздел демонтируется при завершении сессии. В сочетании с модулем pam_ldap это даёт возможность использования комплекса Samba/OpenLDAP для аутентификации и управления пользовательскими каталогами в Linux. Помимо этого, pam_mount может выполнять монтирование при входе разделов разных типов, в том числе зашифрованных, например, с использованием loop и AES.

pam_mount может использоваться совместно с драйверами FUSE (например, Rclone, s3fs-fuse) для монтирования облачных хранилищ^[19]. В контейнерных средах, таких как Kubernetes, модули монтирования PAM не используются, а применяется нативный интерфейс Container Storage Interface (CSI)^[20].

В модуле pam_pkcs11 были выявлены уязвимости (CVE-2025-24031, CVE-2025-24032, CVE-2025-24531), которые могут приводить к отказу в обслуживании и обходу аутентификации. Проблемы связаны с ошибками при прерывании ввода PIN-кода, небезопасной конфигурацией по умолчанию и некорректной обработкой аппаратных сбоев^[21].

Уязвимость EUVD-2026-29474 в модуле pam_authnft связана с чтением данных за пределами выделенного буфера в функции peer_lookup_tcp.

Для обнаружения вредоносных PAM-модулей (бэкдоров) применяются такие методы, как мониторинг целостности конфигурационных файлов в каталоге /etc/pam.d/ и библиотек в /lib/security/, поведенческий анализ, а также аудит системных журналов аутентификации^[22].

Несмотря на проводимые работы по стандартизации^[23], по состоянию на 2023 год PAM не является официальным стандартом. Поведение системы может различаться между разными реализациями.