Внутреннее устройство Linux - Уорд Брайан (читать книги полностью .txt) 📗

auth       requisite       pam_shells.so

auth       sufficient      pam_unix.so

auth       required        pam_deny.so

В соответствии с этой конфигурацией, после того как команда chsh запрашивает PAM-утилиту о выполнении функции аутентификации, утилита выполняет следующее (см. блок-схему на рис. 7.4).

1. Модуль pam_rootok.so проверяет, не пытается ли пройти аутентификацию корневой пользователь. Если это так, то происходит немедленное успешное завершение и дальнейшая аутентификация не предпринимается. Это срабатывает, поскольку для управляющего аргумента установлено значение sufficient, которое означает, что успешного завершения данного действия достаточно, чтобы утилита PAM немедленно возвратила результат команде chsh. В противном случае она переходит ко второму шагу.

2. Модуль pam_shells.so проверяет, есть ли оболочка пользователя в файле /etc/shells. Если ее там нет, модуль возвращает отказ, а управляющий аргумент requisite говорит о том, что утилита PAM должна немедленно сообщить об отказе команде chsh и не пытаться продолжать аутентификацию. В противном случае, когда оболочка есть в файле /etc/shells, модуль возвращает результат, который удовлетворяет флагу required, переходя к третьему шагу.

3. Модуль pam_unix.so запрашивает у пользователя пароль и проверяет его. Для управляющего аргумента указано значение sufficient, поэтому успешной проверки (пароль верный) достаточно для утилиты PAM, чтобы она сообщила об этом команде chsh. Если пароль неверный, утилита PAM переходит к четвертому шагу.

4. Модуль pam_deny.so всегда вызывает отказ, а поскольку присутствует управляющий аргумент required, утилита PAM возвращает отказ команде chsh. Этот вариант применяется по умолчанию в тех случаях, когда больше нечего пробовать. Обратите внимание на то, что управляющий аргумент required не приводит к моментальному отказу функции PAM — она обработает все остальные строки стека, — однако в результате в приложение всегда вернется отказ.

примечание

Не смешивайте термины «функция» и «действие», когда работаете с утилитой PAM. Функция является целью верхнего уровня: что ожидает пользовательское приложение от утилиты PAM (например, выполнить аутентификацию пользователя). Действие является отдельным шагом, который выполняет утилита, чтобы достичь цели. Запомните лишь то, что сначала пользовательское приложение вызывает функцию, а утилита PAM заботится обо всех деталях, связанных с действиями.

Сложный синтаксис управляющего аргумента, помещаемый внутри квадратных скобок ([]), позволяет вручную контролировать реакцию, основываясь на специальном значении, которое возвращает модуль (не только успех или отказ). Подробности см. на странице pam.conf(5) руководства. Когда вы разберетесь с простым синтаксисом, у вас не возникнет затруднений и со сложным.

Рис. 7.4. Процесс исполнения правила PAM

Аргументы модуля

Модули PAM могут задействовать аргументы после имени модуля. Вам часто будет встречаться такой вариант для модуля pam_unix.so:

auth      sufficient    pam_unix.so    nullok

Здесь аргумент nullok сообщает о том, что у пользователя может не быть пароля (по умолчанию в таком случае возник бы отказ).

7.10.2. Примечания о стандарте PAM

Благодаря возможности управления процессом и модульному синтаксису аргументов синтаксис PAM-конфигурации обладает многими чертами языка программирования и некоторыми функциональными возможностями. Мы лишь слегка затронули эту тему, однако приведу еще несколько моментов, относящихся к стандарту PAM.

• Чтобы выяснить, какие модули PAM присутствуют в вашей системе, воспользуйтесь командой man –k pam_ (обратите внимание на символ подчеркивания). Может оказаться непросто выяснить местоположение модулей. Попробуйте команду locate unix_pam.so и посмотрите, к чему это приведет.

• Страницы руководства содержат описание функций и аргументов для каждого модуля.

• Многие версии системы автоматически генерируют некоторые файлы конфигурации PAM, поэтому неразумно изменять их напрямую в каталоге /etc/pam.d. Прочитайте комментарии в этих файлах перед их редактированием; если они были сгенерированы, комментарии скажут вам, откуда взялись файлы.

• Конфигурационные файлы в каталоге /etc/pam.d/other определяют конфигурацию по умолчанию для любого приложения, у которого нет собственного файла конфигурации. Часто по умолчанию на все следует отказ.

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

• Конфигурация PAM не ограничивается лишь аргументами модуля. Некоторые модули могут иметь доступ к дополнительным файлам в каталоге /etc/security, как правило, для настройки ограничений для отдельного пользователя.

7.10.3. Стандарт PAM и пароли

В результате эволюции системы проверки паролей в Linux сохранилось несколько артефактов, которые иногда могут привести к путанице. Во-первых, следует опасаться файла /etc/login.defs. Это файл конфигурации для исходного набора shadow-паролей. Он содержит информацию об алгоритме шифрования, использованном для файла shadow, однако редко применяется в современных системах с установленными модулями PAM, поскольку конфигурация PAM уже содержит данную информацию. Учитывая сказанное, алгоритм шифрования, указанный в файле /etc/login.defs, должен совпадать с конфигурацией PAM — для тех редких случаев, когда вам встретится приложение, не поддерживающее стандарт PAM.

Откуда утилита PAM получает информацию о схеме шифрования пароля? Вспомните о том, что она может взаимодействовать с паролями двумя способами: с помощью функции auth (для проверки пароля) и функции password (для установки пароля). Проще отследить параметр, устанавливающий пароль. Лучшим способом будет, вероятно, простое использование команды grep:

$ grep password.*unix /etc/pam.d/*

Соответствующие строки должны содержать имя pam_unix.so и выглядеть, например, так:

password      sufficient     pam_unix.so obscure sha512

Аргументы obscure и sha512 говорят утилите PAM о том, что следует делать при установке пароля. Сначала утилита проверяет, является ли пароль достаточно «скрытным» (то есть, среди прочего, не напоминает ли он предыдущий пароль), а затем использует алгоритм SHA512, чтобы зашифровать новый пароль.

Однако так происходит только тогда, когда пользователь устанавливает пароль, а не когда утилита PAM проверяет его. Как же ей узнать, какой алгоритм использовать при аутентификации? К сожалению, конфигурация не сообщит ничего; у модуля pam_unix.so нет аргументов шифрования для функции auth.

Оказывается (на момент написания книги), модуль pam_unix.so просто пытается угадать алгоритм, как правило призывая на выполнение этой грязной работы библиотеку libcrypt, которая перебирает множество различных вариантов, пока что-либо не сработает или будет нечего пробовать. Следовательно, вам не придется заботиться об алгоритме шифрования при верификации.

7.11. Заглядывая вперед

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

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