PAM
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 для некоего сервиса:
# Аутентификация
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 будет иметь значение, если это единственный модуль в стеке. |
include
|
Includes the contents of another PAM module's configuration file which matches the given type. |
Цепочки модулей позволяют выполнить множественную аутентификацию, выполнить несколько задач в процессе создания сеанса и тому подобное.
Управление файлами конфигурации PAM
Так как конфигурационные файлы PAM управляют процессом аутентификации в приложении, очень важно правильно с ними взаимодействовать. Файлы обычно располагаются в каталоге /etc/pam.d/.
В больших организациях или в требовательных к безопасности системах любая модификация конфигурационных файлов PAM должна подвергаться соответствующему аудиту.
Это же относится к тому месту, где располагаются модули PAM (/lib/security или /lib64/security).
PAM и Gentoo
Для приложений, поддерживающий PAM, принудительно включён USE-флаг pam
. Хотя и возможно создать систему Gentoo без поддержки PAM (USE="-pam"
), но по умолчанию поддержка PAM включена.
When upgrading remote systems it is possible to leave the system inaccessible. To avoid this after an upgrade while being still logged in to the machine:
- check that logging is up and running
- check necessary configuration updates in /etc/ssh and /etc/pam.d
- check news items whether breaking changes were introduced, e.g. PAM related news Item
- check that changing passwords works flawlessly, e.g. passwd for root/ any user and cancel before actually changing the password
- restart SSH server in case it got updated
- check that a new login to the remote machine works
What could happen:
- without logging errors during the checks cannot be analyzed
- passwd errors out because of PAM module errors
- SSH prohibits login because of PAM misconfiguration/ module errors, e.g. plain connection closed
- password policies changed, e.g. prohibiting root without password
Example of how to parse system configuration
In this forum post in 2021 given by GDH-gentoo, the configuration of a system is tracked down step-by-step, in order to find which service creates the directory /run/user/<uid> on a user login.
См. также
- PAM (Руководство по безопасности) — Although the default PAM settings in Gentoo are reasonable, there is always room for improvement.
- PAM/U2F — provides two-factor authentication through a FIDO U2F USB device, allowing users to authenticate at a press of a button against their system.
- PAM securetty — restricting root authentication with PAM.
- pam_ssh_agent_auth — is the PAM module that allows a locally installed SSH key to authenticate for sudo
- Google Authenticator — describes an easy way to setup two-factor authentication on Gentoo.
- OATH-Toolkit — toolkit for (OTP) One-Time Password authentication using HOTP/TOTP algorithms.
- YubiKey — a hardware security device that can be used to safely store cryptographic keys, OTP tokens, and challenge response seeds
Внешние ресурсы
- Working with PAM, раздел руководства разработчика Gentoo