Управление механизмами аутентификации и авторизации через модули PAM

PAM (Pluggable Authentication Modules) — это модульная архитектура, предназначенная для реализации механизмов аутентификации, авторизации, управления сессиями и паролями в ОС РОСА "ХРОМ". Система PAM обеспечивает унифицированный программный интерфейс между прикладными программами (например, sshd, login, su, sudo, gdm и др.) и механизмами проверки подлинности пользователей.

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

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

Механизм работы PAM

Работа системы PAM строится вокруг понятия "стек аутентификации", в рамках которого выполняется последовательный вызов определённых модулей в установленном порядке. Для каждого прикладного сервиса (например, sshd, login, sudo, gdm-password) создаётся отдельный конфигурационный файл в каталоге /etc/pam.d/.

Каждая строка в конфигурационном файле имеет следующую структуру:

<тип> <контроль> <модуль> [аргументы]

где:

тип (type) – указывает назначение модуля:
- auth – проверка подлинности пользователя (например, ввод пароля или PIN-кода);
- account – проверка политики доступа и допустимости входа (например, срок действия учётной записи, членство в группе);
- password – управление паролем (например, смена, проверка сложности, политика смены);
- session – инициализация и завершение пользовательской сессии (например, монтирование ресурсов, логирование активности).
контроль (control flag) – определяет, как результат выполнения модуля влияет на общее решение (разрешить или запретить доступ):
- required – модуль должен выполниться успешно; при ошибке вход будет запрещён, даже если другие модули завершатся успешно;
- requisite – аналогично required, но при ошибке выполнение следующих модулей будет прекращено;
- sufficient – при успешном выполнении модуля дальнейшая проверка может быть пропущена, если это допускается конфигурацией;
- optional – результат выполнения модуля игнорируется, если он не является единственным в своей категории;
- include – подключение правил из другого PAM-файла;
- substack – подключение стека из другого файла с сохранением логики типа.
модуль – путь к библиотеке или её имя (если библиотека находится в стандартном каталоге /lib/security/ или /lib64/security/);
аргументы – параметры, передаваемые модулю (например, try_first_pass, nullok, debug, inactive=N и т.д.).

Пример записи:

auth required pam_unix.so try_first_pass nullok

Данная строка означает, что при аутентификации (auth) обязательно требуется успешное выполнение модуля pam_unix, использующего локальные пароли пользователей. Модуль будет использовать ранее введённый пароль (если он уже есть в стеке PAM). Опция nullok допускает обработку пустого пароля, однако в сертифицированной конфигурации использование пустых паролей запрещено политикой безопасности.

В ОС РОСА "ХРОМ" используются два уровня конфигурации PAM:

Общие шаблоны, которые располагаются в файлах:
- /etc/pam.d/system-auth;
- /etc/pam.d/password-auth.

Эти файлы содержат общие правила аутентификации, применяемые по умолчанию во всех сервисах через директивы include system-auth или include password-auth. Изменения, внесённые в эти файлы, распространяются на большинство сервисов.

Специфические настройки для сервисов. Каждый сервис может переопределить или дополнить правила PAM в своём отдельном файле, например:
- /etc/pam.d/login – консольный вход (TTY);
- /etc/pam.d/sshd – вход по SSH;
- /etc/pam.d/sudo – выполнение команд от имени другого пользователя;
- /etc/pam.d/gdm-password – вход через графический интерфейс GDM.

При наличии противоречий между общими и локальными файлами приоритет имеет локальный файл конкретного сервиса.

Пример включения общих правил:

auth include system-auth

Эта директива указывает PAM использовать те же правила аутентификации, что и в файле /etc/pam.d/system-auth.

Конфигурация распространённых модулей PAM

Аутентификация через локальные пароли (модуль pam_unix.so)

Модуль pam_unix.so является базовым модулем для аутентификации и управления паролями с использованием локальной базы данных пользователей /etc/passwd и /etc/shadow.

Модуль pam_unix.so обеспечивает стандартную проверку пароля путём сравнения введённого значения с хешем, хранящимся в /etc/shadow. При смене пароля также используется модуль pam_unix.so, если в стеке PAM он подключён в секции "password". Модуль поддерживает использование различных параметров, позволяющих более гибко управлять политиками безопасности, например: ограничением на использование пустых паролей, принудительным использованием одного и того же пароля в цепочке модулей и др.

Основные параметры модуля:

nullok – разрешение входа при пустом пароле (недопустимо в сертифицированной конфигурации);
try_first_pass – попытка использовать уже введённый пароль из предыдущего модуля;
use_authtok – обязательное использование пароля, полученного от предыдущего модуля (обычно используется в стеке password);
shadow – чтение паролей из /etc/shadow (по умолчанию включено).

Пример использования:

auth        sufficient    pam_unix.so try_first_pass nullok
account     required      pam_unix.so
password    sufficient    pam_unix.so use_authtok

Управление переменными окружения при входе (модуль pam_env.so)

Модуль pam_env.so используется для задания и инициализации переменных окружения в сеансах пользователей при аутентификации через PAM. Он позволяет определить, какие переменные среды должны быть установлены, а также откуда они должны быть загружены.

Конфигурационные файлы модуля pam_env.so:

/etc/security/pam_env.conf – основной файл, содержащий переменные окружения в формате "ключ=значение". Может содержать как статические переменные, так и значения, полученные из текущего окружения.
/etc/environment – альтернативный источник переменных окружения. Он используется как вспомогательный механизм и поддерживает только простые объявления переменных без логики и условий.

Модуль pam_env.so выполняется до выполнения остальных PAM-модулей и позволяет задать окружение, которое будет использоваться в рамках сеанса пользователя. Это может быть полезно, например, для установки языковых локалей (LANG, LC_ALL), прокси-переменных, путей к пользовательским скриптам и т. д.

Конфигурационный файл /etc/security/pam_env.conf поддерживает:

комментарии (начинаются с "#");
подстановки переменных (например, ${home});
управление значениями на основе текущего окружения.

Ограничение попыток входа (модуль pam_faillock.so)

Модуль pam_faillock.so отвечает за реализацию механизма блокировки учётной записи после нескольких неудачных попыток входа. Рекомендуется для защиты от атак перебора паролей.

Блокировка применяется как для локального входа (через TTY, GDM), так и для удалённого (через SSH), если PAM настроен соответствующим образом. Модуль сохраняет информацию о неудачных попытках входа и отслеживает их накопление для каждой учётной записи.

Блокировка через pam_faillock.so действует только на вход через PAM. Вызовы, обходящие PAM, не учитываются.

По умолчанию модуль использует файл /var/log/faillock для хранения состояния.

Модуль работает в двух режимах:

preauth – анализирует количество предыдущих неудачных попыток до выполнения основной аутентификации;
authfail – регистрирует неудачную попытку после того, как пользователь ввёл неверный пароль.

При достижении заданного количества попыток доступ блокируется на определённый промежуток времени (unlock_time) или до административной разблокировки.

Основные параметры:

preauth – активация проверки до ввода пароля;
authfail – регистрация неудачной попытки после неверного пароля;
deny=N – максимальное количество попыток перед блокировкой (по умолчанию: 3);
unlock_time=T – продолжительность блокировки в секундах;
fail_interval=T – время, за которое считаются попытки (по умолчанию: 900);
even_deny_root – распространение блокировки на пользователя root (недопустимо применять в сертифицированной конфигурации, чтобы избежать потери административного доступа);
audit – запись в системный журнал о блокировках и разблокировках;
silent – скрытие вывода о количестве оставшихся попыток;
local_users_only – применение только к локальным пользователям;
no_log_info – отключение дополнительной информации в выводе.

Администратор может вручную удалить информацию о блокировках, тем самым разблокировав пользователя. Команда может использоваться только уполномоченным администратором в рамках регламентных процедур. Пример команды:

faillock --user <имя_пользователя> --reset

Просмотр статистики неудачных попыток:

faillock --user <имя_пользователя>

Пример конфигурации /etc/pam.d/system-auth для блокировки учетной записи пользователя после N неудачных попыток входа:

auth     required      pam_faillock.so preauth silent deny=5 unlock_time=900
auth     required      pam_unix.so
auth     [default=die] pam_faillock.so authfail deny=5 unlock_time=900
account  required      pam_faillock.so

В данном примере при пяти неудачных попытках вход блокируется на 15 минут.

Ограничение ресурсов пользователей (модуль pam_limits.so)

Модуль pam_limits.so отвечает за применение ограничений на ресурсы пользователей (число процессов, размер памяти, количество открытых файлов и др.).

Ограничения применяются в соответствии с конфигурационными файлами limits.conf и дополнительными файлами из каталога /etc/security/limits.d/.

Ограничения вступают в силу при открытии новой сессии, поэтому необходимо убедиться, что pam_limits.so подключён в секции "session" соответствующего PAM-файла (например, login, sshd, su, gdm-password и др.).

Ограничения могут устанавливаться по следующим ресурсам:

core – максимальный размер файла core dump (в блоках);
data – максимальный размер сегмента данных процесса;
fsize – максимальный размер создаваемого файла (в блоках);
memlock – максимальный объём заблокированной памяти;
nofile – максимальное количество открытых файлов;
nproc – максимальное количество процессов пользователя;
rss – максимальный объём оперативной памяти;
stack – максимальный размер стека;
cpu – лимит времени процессора (в минутах);
maxlogins – максимальное количество одновременных логинов;
priority – приоритет (nice) запускаемых процессов (настройка приоритета процессов должна выполняться только в соответствии с политикой безопасности и не должна нарушать функционирование системных служб.);
locks – максимальное количество блокировок файлов;
sigpending – максимальное количество ожидающих сигналов;
msgqueue – максимальный объём POSIX-очередей сообщений;
nice – максимально допустимое значение nice;
rtprio – максимальный приоритет реального времени.

Каждая строка в файлах имеет следующий формат:

<домен> <тип> <ресурс> <значение>

<домен> – имя пользователя, группа (@groupname) или спец. символ * (все пользователи);
<тип> – soft (мягкое ограничение), hard (жёсткое ограничение) или "-" (оба сразу);
<ресурс> – название ограничиваемого ресурса;
<значение> – числовое значение ограничения или unlimited.

Настройки ограничений применяются со следующим приоритетом и порядком:

настройки из /etc/security/limits.d/*.conf дополняют или переопределяют правила из limits.conf при совпадении домена и ресурса;
приоритет имеют правила, указанные позже (например, в алфавитном последнем файле из limits.d);
если для одного пользователя задано несколько значений одного ресурса, используется более строгое (жёсткое) ограничение.

Некоторые ограничения (например, nofile) могут быть переопределены средствами оболочки или системным демоном (например, systemd user services). В таких случаях требуется дополнительная настройка через systemd (директивы LimitNOFILE= и т.п.).

При отладке рекомендуется использовать команду ulimit -a для просмотра текущих применённых ограничений к сессии.

Примеры конфигурации модуля:

Ограничение количества процессов:

@developers  soft  nproc  2048
@developers  hard  nproc  4096

Ограничение количества одновременно открытых файлов:

user1  -  nofile  1024

Принудительное окончание сессии и ограничение пользователя одной активной сессией (например, для терминального сервера). Изменения вносятся в файл /etc/security/limits.d/10-maxlogins.conf:

* hard maxlogins 1

Проверка условий доступа (модуль pam_succeed_if.so)

Модуль pam_succeed_if.so используется для условного выполнения последующих или текущих PAM-модулей в зависимости от заданных условий. Применяется для реализации гибкой логики доступа, например, разрешения или запрета входа определённым группам пользователей, пользователям с конкретными идентификаторами (UID), оболочками (shell), типами сервисов и т.д. Это особенно полезно при создании дифференцированных правил аутентификации в различных сценариях: GDM, TTY, SSH и других.

Модуль pam_succeed_if.so не выполняет саму аутентификацию, а лишь влияет на ход выполнения PAM-стека, пропуская или блокируя модули по заданным условиям.

Основные параметры модуля:

user ingroup <имя_группы> — проверка, состоит ли пользователь в указанной группе;
uid < N / uid >= N — проверка числового идентификатора пользователя (например, для различия между системными и обычными пользователями);
shell = /bin/bash — проверка используемой оболочки пользователя;
service = gdm — проверка PAM-сервиса (имя PAM-конфигурационного файла), в рамках которого вызывается модуль.

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

[default=1 success=ignore] — при выполнении условия переход к следующему модулю, в противном случае — пропуск следующего модуля;
[success=ok default=bad] — возврат успешного статуса при выполнении условия, иначе — неудача.

Пример использования для ограничения входа только пользователям, состоящим в группе tokenlogin, используется следующая строка в PAM-конфигурации:

auth [default=1 success=ignore] pam_succeed_if.so user ingroup\ tokenlogin
auth requisite pam_deny.so

Модуль pam_deny.so используется для принудительного отказа в доступе при нарушении условий политики.

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

Данное правило может быть добавлено, например, в начало файла /etc/pam.d/system-auth или /etc/pam.d/login.

Аутентификация с использованием токенов и смарт-карт (модуль pam_p11.so)

Модуль pam_p11.so предназначен для аутентификации пользователей с использованием аппаратных токенов (по стандарту PKCS#11). Используется в рамках реализации двухфакторной аутентификации в ОС РОСА "ХРОМ". pam_p11.so позволяет выполнять проверку подлинности за счёт криптографической подписи, формируемой закрытым ключом, хранящимся на токене.

Особенности работы модуля:

Модуль взаимодействует с аппаратным токеном напрямую через PAM и не зависит от наличия службы sshd или ключей OpenSSH.
Применяется как для локального входа, так и в составе универсальных PAM-стеков, например, для GDM, SSH, TTY и других служб.
В сценарии двухфакторной аутентификации модуль инициирует запрос PIN-кода от токена и проверяет криптографическую подпись случайной последовательности, тем самым реализуя второй фактор.

Подробные инструкции по подготовке токена, настройке целевой и рабочей станции, а также интеграции pam_p11.so с различными сервисами приведены в разделе Настройка двухфакторной аутентификации.

Блокирование неактивных учётных записей

Для обеспечения безопасности и минимизации риска использования забытых или устаревших учётных записей модуль pam_lastlog позволяет реализовать блокирование входа пользователей, не осуществлявших вход в Систему в течение определённого количества дней.

Блокирование при входе через GDM

Для включения блокировки неактивных учётных записей при входе через графический менеджер входа (по умолчанию используется GDM) требуется внести изменения в файл /etc/pam.d/password-auth. Для этого необходимо:

открыть файл для редактирования с правами суперпользователя:

sudo nano /etc/pam.d/password-auth

добавить в него строку:

auth required pam_lastlog.so inactive=90

между строками:

auth required pam_env.so

и:

auth sufficient pam_unix.so try_first_pass

также добавить строку:

account required pam_lastlog.so inactive=90

перед строкой:

account required pam_unix.so

Параметр inactive=90 указывает, что вход будет заблокирован, если последний вход пользователя был выполнен более 90 суток назад. При необходимости значение может быть изменено в соответствии с политикой безопасности организации.

Блокирование при входе через терминал (TTY, SSH)

Для включения аналогичного механизма при входе через терминал или SSH необходимо внести аналогичные изменения в файл /etc/pam.d/system-auth. Для этого необходимо:

открыть файл для редактирования:

sudo nano /etc/pam.d/system-auth

добавить в файл строку:

auth required pam_lastlog.so inactive=90

между строками:

auth required pam_env.so

и:

auth sufficient pam_unix.so try_first_pass likeauth nullok

также добавить строку:

account required pam_lastlog.so inactive=90

перед строкой:

account required pam_unix.so

Данная конфигурация блокирует доступ к Системе пользователям, чья учётная запись не использовалась в течение указанного срока.

Просмотр справки по модулю pam_lastlog

Для получения дополнительной информации о возможных параметрах модуля pam_lastlog рекомендуется использовать встроенную справку:

man pam_lastlog

Отладка и проверка работы PAM

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

Просмотр системного журнала

Большинство PAM-модулей, включая pam_unix, pam_faillock, pam_lastlog, pam_p11, записывают диагностические сообщения в системный журнал. Для просмотра сообщений, связанных с PAM, рекомендуется использовать команду:

sudo journalctl -b | grep pam

Для анализа конкретного модуля, например, pam_p11, используется команда:

sudo journalctl -b | grep pam_p11

Параметр -b ограничивает вывод сообщениями текущей загрузки Системы.

Проверка конфигурации и тестирование изменений

Изменения PAM могут выполняться только уполномоченным администратором и в соответствии с политикой безопасности организации.

Перед внесением изменений в основные PAM-файлы (например, /etc/pam.d/system-auth, /etc/pam.d/password-auth, /etc/pam.d/sshd) рекомендуется, предварительно обязательно создав резервную копию изменяемого файла:

sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak

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

Если вход становится невозможен, следует восстановить резервную копию из открытой сессии:

sudo cp /etc/pam.d/system-auth.bak /etc/pam.d/system-auth

Использование временного доступа через root-tty

Для минимизации рисков полной потери доступа к Системе рекомендуется:

оставлять root-доступ через терминал TTY активным (файл /etc/pam.d/login);
не изменять правила PAM для sudo, su и login одновременно;
иметь доступ к Системе через физическую консоль или загрузку в однопользовательском режиме (recovery mode), если доступ по SSH будет заблокирован.

Примеры отладочной информации от модулей

Для повышения информативности можно включить режим отладки в отдельных модулях:

В модуле pam_unix:

auth required pam_unix.so debug

В модуле pam_faillock:

auth required pam_faillock.so preauth silent deny=5\ unlock_time=900 debug

Сообщения с пометкой pam_unix(debug) или pam_faillock(debug) будут отображаться в journalctl.

Режим debug предназначен исключительно для диагностических задач и не должен оставаться включённым в рабочей (промышленной) конфигурации сертифицированной ОС.

Проверка порядка выполнения модулей

Для анализа последовательности выполнения PAM-модулей можно использовать повышенное логирование, активируемое на уровне службы (например, sshd). Для этого в файле /etc/ssh/sshd_configнеобходимо добавить или изменить параметр:

LogLevel DEBUG

После этого нужно перезапустить службу:

sudo systemctl restart sshd

В journalctl будут отображаться дополнительные сведения о ходе аутентификации.

После завершения диагностики рекомендуется вернуть значение LogLevel в стандартное (INFO).