Когда стандартная библиотека является используемой совместно, можно осуществить значительные изменения в реализации системы, не меняя никаких других команд. Например, можно полностью уйти от применения файла /etc/passwd для ваших пользователей и применять вместо него сетевую службу, подобную LDAP (Lightweight Directory Access Protocol, облегченный (упрощенный) протокол доступа к (сетевым) каталогам).
Такой подход прекрасно работает при идентификации имен пользователей, связанных с идентификаторами, однако для паролей дела обстоят сложнее. В подразделе 7.3.1 описано, каким обычно образом зашифрованный пароль становится частью файла /etc/passwd, поэтому, если бы вам понадобилось проверить введенный пользователем пароль, пришлось бы шифровать все, что вводит пользователь, и сравнивать с содержимым файла /etc/passwd.
Традиционная реализация обладает следующими ограничениями.
• Не устанавливается общесистемный стандарт на протокол шифрования.
• Предполагается, что у вас есть доступ к зашифрованному паролю.
• Предполагается, что пользователю будет предлагаться ввести пароль всякий раз, когда он будет пытаться получить доступ к чему-либо, требующему аутентификации.
• Предполагается, что вы намерены использовать именно пароли. Если вы желаете применять одноразовые жетоны, смарт-карты, биометрическую или какую-либо еще аутентификацию пользователя, вам придется добавлять такую поддержку самостоятельно.
Некоторые ограничения, посодействовавшие развитию пакета shadow-паролей, рассмотрены в подразделе 7.3.3. Этот файл сделал первый шаг к тому, чтобы разрешить конфигурирование паролей на уровне системы в целом. Однако решение большинства проблем пришло вместе с разработкой и реализацией стандарта PAM.
7.10. Стандарт PAM
Чтобы обеспечить гибкость при аутентификации пользователей, в 1995 году корпорация Sun Microsystems предложила новый стандарт под названием PAM (Pluggable Authentication Modules, подключаемые модули аутентификации) — систему совместно используемых библиотек для аутентификации (рабочие предложения Open Source Software Foundation, выпуск 86.0, октябрь 1995 года). Для аутентификации пользователя приложение «вручает» пользователя утилите PAM, чтобы определить, может ли пользователь успешно идентифицировать себя. Таким образом сравнительно легко добавить поддержку дополнительных методов, таких как двухфакторная аутентификация или ключи на материальных носителях. В дополнение к поддержке механизма аутентификации стандарт PAM также обеспечивает ограниченную степень контроля авторизации для служб (если, например, вы желаете, чтобы у некоторых пользователей не было службы cron).
Поскольку существуют различные типы аутентификации, стандарт PAM использует несколько динамически загружаемых модулей аутентификации. Каждый модуль выполняет специальную задачу; например, модуль pam_unix.so проверяет пароль пользователя.
Занятие это довольно сложное. Программный интерфейс непростой, и неясно, действительно ли стандарт PAM справляется со всеми существующими проблемами. Однако поддержка стандарта PAM присутствует практически в каждой команде, для которой требуется аутентификация в системе Linux, и большинство версий системы используют этот стандарт. Поскольку он работает поверх интерфейса API для аутентификации, существующего в Unix, интеграция поддержки в клиент требует незначительной (а то и совсем никакой не требует) дополнительной работы.
7.10.1. Конфигурация PAM
Мы изучим основы стандарта PAM, рассмотрев его конфигурацию. Файлы конфигурации PAM обычно можно найти в каталоге /etc/pam.d (в старых системах может использоваться единственный файл /etc/pam.conf). Во многих версиях содержится несколько файлов, и может быть неясно, с чего начать. Определенные имена файлов должны соответствовать частям системы, которые вы уже знаете, например cron и passwd.
Поскольку специальная конфигурация в таких файлах может сильно различаться в разных версиях системы, трудно подыскать общий пример. Рассмотрим образец строки конфигурации, который вы можете обнаружить для команды chsh (команда смены оболочки):
auth requisite pam_shells.so
Эта строка говорит о том, что оболочка пользователя должна располагаться в каталоге /etc/shells, чтобы пользователь мог успешно пройти аутентификацию команды chsh. Посмотрим, каким образом. Каждая строка конфигурации содержит три поля в таком порядке: тип функции, управляющий аргумент и модуль. Вот что они означают для данного примера.
• Тип функции. Это функция, которую пользовательское приложение просит выполнить утилиту PAM. В данном случае это команда auth, задание аутентификации пользователя.
• Управляющий аргумент. Этот параметр контролирует то, что будет делать PAM-приложение после успешного или неудачного завершения действия в данной строке (requisite в этом примере). Скоро мы перейдем к этому.
• Модуль. Это модуль аутентификации, который запускается для данной строки и определяет, что именно делает строка. Здесь модуль pam_shells.so проверяет, упоминается ли текущая оболочка пользователя в файле /etc/shells.
Конфигурация PAM детально описана на странице руководства pam.conf(5). Рассмотрим некоторые основные части.
Типы функций
Пользовательское приложение может попросить PAM-утилиту выполнить одну из четырех перечисленных ниже функций:
• auth — выполнить аутентификацию пользователя (проверить, является ли пользователь тем, кем он себя называет);
• account — проверить статус учетной записи пользователя (авторизован ли, например, пользователь на выполнение каких-либо действий);
• session — выполнить что-либо только для текущего сеанса пользователя (например, отобразить сообщение дня);
• password — изменить пароль пользователя или другую информацию в учетной записи.
Для любой строки конфигурации модуль и функция совместно определяют действие PAM-утилиты. У модуля может быть несколько типов функции, поэтому при определении назначения строки конфигурации всегда помните о том, что функцию и модуль следует рассматривать в виде пары. Например, модуль pam_unix.so проверяет пароль, когда выполняет функцию auth, но если он выполняет функцию password, то пароль устанавливается.
Управляющие аргументы и стек правил
Одним важным свойством стандарта PAM является то, что правила, которые определены в строках конфигурации, образуют стек, это значит, что можно применять несколько правил при выполнении функции. Именно поэтому важен управляющий аргумент: успешное или неудачное завершение действия в одной строке может повлиять на следующие строки или привести к тому, что сама функция завершит работу корректно или нет.
Существуют два типа управляющих аргументов: с простым и более сложным синтаксисом. Приведу три главных управляющих аргумента с простым синтаксисом, которые вы можете найти в правиле.
• sufficient. Если данное правило выполняется успешно, аутентификация также проходит успешно и PAM-утилите не нужно проверять следующие правила. Если правило не выполняется, утилита PAM переходит к дополнительным правилам.
• requisite. Если правило выполняется успешно, PAM-утилита переходит к следующим правилам. Если правило не выполняется, аутентификация завершается неудачей и PAM-утилите не нужно проверять следующие правила.
• required. Если данное правило выполняется успешно, PAM-утилита переходит к следующим правилам. Если правило не выполняется, PAM-утилита переходит к следующим правилам, но всегда вернет отрицательный результат аутентификации, вне зависимости от результатов выполнения дополнительных правил.
Продолжая предыдущий пример, приведу образец стека для функции аутентификации chsh:
auth sufficient pam_rootok.so