Pluggable Authentication Modules (PAM)

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

Pluggable Authentication Modules (PAM) - это способ, позволяющий системному администратору задавать правила аутентификации без перекомпиляции программ аутентификации. Используя PAM, вы настраиваете определенные модули, включаемые в программу, редактируя конфигурационный PAM файл программы в /etc/pam.d.

Большинство пользователей Red Hat Linux никогда не нуждаются в изменении конфигурационных PAM файлов их программ. Когда вы используете RPM для установки программ, требующих аутентификации, они автоматически вносят необходимые для нормальной работы изменения. Однако, если вам понадобится изменить вашу конфигурацию, вы должны понимать стуктуру конфигурационного файла PAM. Больше информации вы можете найти в разделе "модули PAM".

Преимущества PAM

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

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

Конфигурационные файлы PAM.

Каталог /etc/pam.d содержит в себе конфигурационные файлы PAM. В ранних версиях PAM использовался файл pam.conf. Этот файл будет использоваться если не было найдено каталога /etc/pam.d, однако его использование нежелательно.

Каждое приложение (или сервис, используемый многими пользователями) имеет собственный файл. Каждый файл имеет пять разных элементов: имя сервиса, тип модуля, флаги управления, путь к модулю и аргументы.

Имена сервисов PAM.

Имя сервиса каждого приложения использующего PAM - это имя его файла конфигурации в /etc/pam.d. Каждое приложение, использующее PAM определяет собственное имя сервиса.

Например, программа login определяет имя login, программа ftpd - ftpd, и так далее.

В общем, имя сервиса - это имя программы использующей сервис, а не программы его предоставляющей.

Модули PAM.

PAM включает четыре типа модулей для управления доступом к определенному сервису:

Auth модуль предоставляет фактичкескую аутентификацию (возможно запрашивает и проверяет пароль) и устанавливает удостоверения (credentials) такие как членство в группе или Kerberos tickets.
Account модуль проверяет, разрешена ли регистрация данного пользователя в данный момент (не истекло ли время дествия аккаунта, разрешено ли пользователю регистрироваться в данный момент и т. п.)
Password модуль используется для установки паролей пользователя.
Session модуль используется после того как пользователь прошел регистрацию. Этот модуль позволяет использовать кому-то его аккаунт (например, монтировать домашний каталог пользователя или делать доступным его почтовый ящик).

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

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

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

Прежде, чем кто-либо получит доступ к xlogin, PAM проверит отсутствие /etc/nologin, что это не попытка удаленной регистрации под root, и что ни одной переменной окружения не может быть загружено. Затем необходимо успешное выполнение аутентификации xhosts, для того, чтобы позволить установить соединение. Если аутентификация xhosts завершается неудачей, то выполняется стандартная password аутентификация.

Новые PAM модули могут добавляться в любое время, после чего приложения использующие PAM могут работать с ними. Например, если вы создаете one-time-password creation метод и пишете PAM модуль для его поддержки, ваши программы могут сразу его использовать, не требуя перекомпиляции либо других изменений. Как вы уже заметили, это очень полезно, потому как вы можете легко выбирать необходимы компонеты, смешивать их и довольно легко отлаживать получившееся. Методы аутентификации для любых программ можно строить легко и быстро, и у вас нет необходимости перекомпилировать программу или нвосить в нее изменения другого рода.

Документацию касательно написания модулей вы можете найти в /usr/share/doc/pam?(version-number).

Флаги управления PAM.

Каждый модуль PAM возвращает результат успешного выполнения или неудачи. Флаги управления говорят PAM, что нужно делать с результатом. Когда модули расположены в определенной последовательности, флаги дают вам возможность установить "важность" модуля по отношению к следующему за ним.

Вернемся к нашему конфигурационному файлу PAM для xlogin:

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

Четыре типа флагов, стандартных для PAM.

required. Такой модуль должен быть успешно пройден. Лишь только в этом случае пользователь будет допущен к проверке следующим модулем.
requisite. Чтобы получить аутентификацию, этот модуль должен также быть успешно пройден. Однако, если requisite модуль не будет пройден, управление передается непосредственно приложению.
sufficient. При проверке, завершившейся неудачей, этот модуль будет просто проигнорирован. Но, если sufficient модуль успешно пройден, и не было неудач при прохождение вышестоящих required модулей, то все остальные модули этого типа больше не будут рассматриваться и будут считаться успешно пройденными.
optional. Успешное или неудачное прохождение модулей этого типа не является критичным для общей картины аутентификации. Модули этого типа играют роль только тогда, когда нет модулей других типов.

В настоящий момент в PAM доступны новые флаги управления. Смотрите документацию PAM в /usr/share/doc/pam?(version-number) для получения информации.

Пути к PAM модулям.

Пути к модулям говорят PAM, где искать подключаемый модуль. Обычно, это представляет собой полный путь к модулю, такой как /lib/security/pam_stack.so. Если путь к модулю не будет указан (или он начинается не с '/', то по-умолчанию считается, что модуль расположен в /lib/security.

Аргументы PAM.

PAM использует аргументы для передачи информации подключаемому модулю во время аутентификации. Аргументы позволяют в различных конфигурационных файлах PAM использовать модули по-разному.

Например, модуль pam_userdb.so использует информацию хранящуюся в файле Berkeley DB для аутентификации пользователя. Этому модулю нужно передать аргумент, определяющий имя используемого файла, который у каждого сервиса свой.

Таким образом, строка pam_userdb.so будет выглядеть следующим образом:

auth required /lib/security/pam_userdb.so db=path/to/file

Неправильные аргументы будут проигнорированы и модуль не вернет никакого результата. Когда встречается неверный аргумент, ошибка обычно фиксируется в /var/log/mesages.

Примеры конфигурационного файла PAM.

Конфигурационный PAM файл приложения может выглядеть так:

#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_unix.so shadow nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_unix.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_unix.so shadow nullok use_authtok
session required /lib/security/pam_unix.so

Первая строка является комментарием (любая строка, начинающаяся с '#' - это комментарий. Строки со второй по четвертую используются для аутнетификации.

auth required /lib/security/pam_securetty.so

Вторая строка проверяет наличие терминала с которого производится попытка а аутентификации в файле /etc/securetty, если таковой существует, в случае root логина. Если tty не указан в файле, то аутентификация не будет разрешена.

auth required /lib/security/pam_unix.so shadow nullok

Третья строка запрашивает у пользователя пароль и проверяет его.

auth required /lib/security/pam_nologin.so

Четвертая строка проверяет наличие файла /etc/nologin. Если файл существует и пользоваетль не является root, аутентификация завершится неудачей.

Заметьте, что все три auth модуля будут обрабатываться одниаково, независимо от того, проход какого модуля завершится неудачей. Такая стратегия не позволяет узнать пользователю какой именно этап аутентификации он не прошел. Знание причин провала аутентификации может стать причиной обхода пользователем этого этапа в следующий раз. Вы можете изменить такое поведение системы, заменив required модуль на requisite. Если какой либо requisite модуль не будет пройден, PAM остановится немедленно и вернет результат неудачи. Остальные существующие модули при этом проверяться не будут.

account required /lib/security/pam_unix.so

Пятая строка производит необходимые проверки аккаунта. Например, если включены теневые пароли, модуль pam_unix.so проверяет время действия аккаунта или своевременную смену пароля пользователем.

account required /lib/security/pam_cracklib.so

Шестая строка проверяет, не могут ли измененные пароли быть взломаны при помощи программ перебирающих по словарю.

password required /lib/security/pam_unix.so shadow nullok use_authtok

Седьмая строка определяет, что если программа login изменяет пароль пользователя, она для этого использует модуль pam_unix.so. Это может произойти, если auth модуль определит, что пароль необходимо сменить - например, если истек срок действия пароля.

Восьмая, и последняя строка определяет, что модуль pam_unix.so будет управлять сеансом (сессией). В данный момент этот модуль ничего не делает; он должен быть заменен на необходимый модуль или дополнен stack'ингом (поправьте меня, кто может).

Обратите внимание на порядок строк в файле. Порядок вызова required модулей не имеет значения, доступны другие флаги управления. Использование в файле optional модулей обуславливает важность порядка выполнения модулей sufficient и requisite.

В качестве следующегь примера рассмотрим конфигурационный файл для rlogin:

#%PAM-1.0
auth      required    /lib/security/pam_nologin.so
auth      required    /lib/security/pam_securetty.so
auth      required    /lib/security/pam_env.so
auth      sufficient  /lib/security/pam_rhosts_auth.so
auth      required    /lib/security/pam_stack.so service=system-auth

Первое. Если существует файл /etc/nologin, никто кроме root не сможет зарегистрироваться в системе.

auth required /lib/security/pam_securetty.so

Второе. pam_securetty.so предотвращает регистрацию root с ненадежных терминалов. Неплохо было бы запретить логиниться root'у при помощи rlogin. Если вы желаете иметь такую возможность (в этом случае вы должны иметь хороший firewall или быть отключенным от интернета), смотрите документацию rlogin.

auth required /lib/security/pam_env.so

Третье. Модуль pam_env.so загружает переменные окружения, описанные в /etc/security/pam_env.conf.

auth sufficient /lib/security/pam_rhosts_auth.so

Четвертое. Если pam_rhosts_auth.so аутентифицирует пользователя используя .rhosts в домашнем каталоге пользователя, PAM передает управление непосредственно rlogin, не переходя к следующему шагу аутентификации (обычной проверки пароля). Если проход модуля pam_rhosts_auth.so завершится неудачей, то будет производиться нормальная проверка пароля (следующий шаг).

auth required /lib/security/pam_stack.so service=system-auth

Пятое. Если pam_rhosts_auth.so не был пройден, pam_stack.so с аргументом service=system-auth производит стандартную password аутентификацию.

NOTE:
Если вы не хотите запрашивать пароль в случае неудачной проверки securetty и определения попытки установления удаленного соединения, вы можете сменить pam_securetty.so с required на requisite. Как вариант, вы можете пожелать разрешить удаленные root регистрации, но это не является хорошей идеей.

Источник:
Red Hat Linux 7.1: The Official Red Hat Linux Reference Guide
Перевод:
Александр Шепетко