Подготовка к экзамену LPI: Управление клиентом сети

Страница 6 из 9  Опции документа Обсудить Выскажите мнение об этом учебном пособии Помогите нам улучшить содержание

Идентификация PAM

Когда используется PAM

Первое, что следует уяснить о Pluggable Authentication Modules (PAM) -- это, что это не есть ни приложение, ни протокол. Правильнее говорить, что это -- коллекция библиотек, которые могут включаться в приложения во время компиляции, чтобы использовать функции этих модулей. Если в приложении включены PAM, политика безопасности этого приложения может задаваться системным администратором, без изменения или обновления самого приложения. Многие утилиты Linux, в особенности демоны и сервера могут использовать PAM.

Быстрый способ выяснить, является ли данное приложение возможно использующим PAM, состоит в использовании ldd, чтобы выяснить, какие библиотеки используются. Например, мне интересно, является ли использующей PAM программа, выполняющая вход в систему:

                    
      % ldd /bin/login | grep libpam
      libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
      libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

Использование libpam.so и libpam_misc.so программой login не полностью гарантирует, что средства PAM действительно используются этими утилитами, и используются правильно, но это -- хороший знак. Подобным образом, мне, возможно, интересно узнать то же про мои сервера Apache и FTP:

                    
      % ldd /usr/sbin/apache2 | grep libpam
      % ldd /bin/login | grep libpam
      libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
      libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

Теперь я точно знаю, что моя сборка Apache не поддерживает PAM (хотя есть версии, для которых это не так).

Для более тщательной проверки, работают ли PAM с данным приложением, для данной программы можно создать конфигурационный файл PAM. Например, для проверки утилиты входа следует создать файл /etc/pam.d/login (однако обратите внимание, что он, возможно, уже имеется в вашей системе, и содержит более важные настройки, так что не удаляйте имеющийся файл):

                    
      auth      required    pam_permit.so
      auth      required    pam_warn.so

Теперь выполнение правильного поддерживающего PAM login позволит осуществит вход, но при этом занесет действия в системный журнал. Если syslog покажет вход, значит для этого приложения PAM задействован. Читатель, наверно, заметит, что это -- наверно, худшая конфигурация, которую можно придумать для login, так как теперь он даст доступ к оболочке каждому. Подметив это, уясните, что настраивать PAM следует с определенной осторожностью.

В начало

Настройка PAM

PAM работает с двумя видами конфигурационных файлов.

Предпочтительный способ настройки PAM состоит в использовании файлов из каталога /etc/pam.d/, которые имеют те же имена, что и службы, чья безопасность является желаемой. Более старый и менее рекомендуемый способ состоит в использовании одного файла, /etc/pam.conf, для указания политики безопасности для всех приложений. С точки зрения возможности поддержки работы, создание по конфигурационному файлу на приложение проще, вместо файлов можно создать символические ссылки для "копирования" политика безопасности от одного приложения на другое. Оба стиля конфигурации в основном совпадают. Единый файл /etc/pam.conf содержит строки вида:

                    
      <service>  <module-type>  <control-flag>  <module-path>  <args>

В конфигурационных файлах отдельных приложений первое поле опускается, поскольку оно такое же,как и имя файла. Тестовая конфигурация входа, которую мы видели, в старом стиле выглядит как:

                    
      login     auth      required    pam_permit.so
      login     auth      required    pam_warn.so

Поле <module-type> может принимать одно из четырех значений:

• auth (аутентификация),
• account (неидентификационные права доступа, основанные на состоянии пользователя в системе),
• session (совершать действия до/после запуска службы), and
• password (обновление tokenов идентификации пользователя).

Поле <control-flag> используется для "stack" модулей, которые позволяют вам вести довольно утонченный контроль того, когда этот метод требуется, требуется ли он вообще, и когда принимается какой-нибудь другой исход. Эти опции таковы:

• required,
• requisite,
• sufficient,
• optional, and
• include.

Я расскажу об этом ниже.

Поле <module-path> уже появлялось в примерах.Оно обозначает разделяемую библиотеку - либо указывая явный путь к ней (если значние начинается с "/", либо только имя (при этом сама библиотека ищется в каталогах по умолчанию). Например, в Listing 17, можно было бы написать /lib/security/pam_warn.so. Полем <args> может быть все, что угодно, в зависимости от того, какой именно модуль требуется для настройки этой операции, хотя несколько аргументов общего типа должны поддерживаться большинством модулей PAM. Обратите внимание, что модули PAM являются расширяемыми. Если кто-нибудь пишет новый модуль PAM, его можно просто поместить в /lib/security и все ваши приложения смогут использовать его, как только их конфигурационный файл будет обновлен.

В начало

Пример прав доступа PAM.

Чтобы увидеть, как работает <control-flag>, давайте сконструируем довольно сложный пример. Первое, что следует сделать -- это создать специальную службуOTHER. Если это сделано, и для этой службы не определена никакая политика PAM, используется политика OTHER. Безопасное default будет пожоже на Listing 18:

                    
      auth      required    pam_warn.so
      auth      required    pam_deny.so
      @include safe-account
      @include safe-password
      @include safe-session

В этом примере, попытка идентификации сначала журналируется, а затем получает отказ. @include просто включает содержимое какого-нибудь файла, например /etc/pam.d/safe-account и подобных, в то время как эти "безопасные" определения должны содержать похожие предупредить-и-отклонить инструкции для других <module-type>-ов.

Теперь давайте настроим доступ к нашему гипотетическому секретному-db приложению. Будучи довольно озабоченным доступом, пользователь должен представить либо соответствующий отпечаток сетчатки глаза, либо отпечаток пальца, либо же ввести пароль. Пароль, однако, должен храниться либо в локальных конфигурациях /etc/passwd и /etc/shadow, или быть доступными посредством одного или двух внешних серверов баз данных.

Ни один из модулей безопасности, которые приводятся в этом примере, в действительности не существуют (насколько мне известно), кроме pam_unix.so, который есть доступ к паролю в устаревшем UNIX-стиле.

                    
      auth      optional    pam_unix.so
      auth      optional    pam_database1.so    try_first_pass
      auth      optional    pam_database2.so    use_first_pass
      auth      requisite   pam_somepasswd.so
      auth      sufficient  pam_fingerprint.so  master=file1 7points
      auth      required    pam_retinaprint.so

Путь через эту конфигурацию весьма сложен. Вначале мы пытаемся идентифицировать пароль тремя optional типами модулей. Поскольку они optional (необязательны), отказ одного ни останавливает процесса идентификации, ни удовлетворяет его. Сначала пробуется стандартный пароль UNIX (пользователя просят ввести пароль). После этого пароль проверяется в database1, но вначале используется общий аргумент модуля try_first_pass, чтобы убедиться, совпадает ли пароль UNIX с паролем в базе данных; дополнительный пароль вводится только в случае несовпадения. Для базы данных database2, однако, мы лишь пытаемся идентифицировать, используя пароль UNIX, введенный пользователем (общий аргумент use_first_pass).

После проверки пароля в нескольких опциональных (optional) системах паролей, у нас есть гипотетический pam_somepasswd.so, которому нужно определить, увенчалась ли успехом какая-нибудь из ранее проведенных проверок паролей (возможно, с использованием семафоров; но вопрос, как это делать остается открытым для гипотетических модулей). Но поскольку эта проверка является requisite(необходимый), то если он не срабатывает, дальнейшая идентификация не производится, и докладывается о неудаче.

Последние две идентификационные проверки (если дело доходит до них) являются sufficient. То есть, удовлетворение одной из них возвращает вызываемому приложению состояние успеха. То есть вначале мы делаем проверку отпечатка пальца, используя pam_fingerprint.so (обратите внимание, что гипотетические аргументы передаются модулю). И только если здесь будет неудача -- может быть, из-за отсутствия сканера отпечатков пальцев, или же из-за плохого отпечатка -- предпринимается попытка сканировать сетчатку глаза. Далее, если сканирование сетчатки имело успех, этого sufficient(достаточно). Однако, чтобы продемонстрировать все возможные опции, мы использовали также required, что означает, что даже если сканирование сетчатки дало успех, следует продолжить проверку другими методами (но в примере других нет, так что sufficient будет делать то же самое).

Также существует способ указать еще более тонко настроенные составные флаги для <control-flag> при помощи взятых в скобки [value1=action1 ...] множеств, но обычно хватает основных ключевых слов.

В начало

	Страница 6 из 9