учебники, программирование, основы, введение в,

 

Аутентификация в сети. PAM

Прежде чем говорить аутентификации, следовало бы определиться с тем, что это такое. Слово "аутентификация" происходит от слова "аутентичность", что означает подлинность, соответствие подлинному, истинному. Иногда "аутентичность" расшифровывают как "соответствие самому себе" (если вы философ, такая формулировка может вам понравиться).
Под аутентификацией в компьютерных сетях понимают процедуру, позволяющую выяснить, является ли субъект тем, за кого себя выдает. Если вы обращаетесь к сервису, предоставляемому не всем, вы должны доказать, что имеете на это право. Сообщив свое имя и пароль, вы идентифицируете себя и так даете серверу понять, что имеете право на сервис, который он предоставляет. Обычно аутентификация состоит именно в сообщении имени и пароля, но есть и более современные технологии аутентификации - с помощью электронных ключей, приборов распознавания образа сетчатки глаза и т.п.
За процедурой аутентификации часто следует авторизация - предоставление пользователю определенных прав доступа к ресурсу. Разным пользователям (и разным группам пользователей) назначаются разные права.
Распространенные схемы аутентификации
В системах UNIX, как правило, выполняется стандартная аутентификация, с использованием файла паролей (/etc/passwd, /etc/shadow). Для централизованной аутентификации на нескольких компьютерах в сети были разработаны разные схемы, связанные с централизованным хранением базы данных пользователей и паролей.
Конечно, надо вспомнить NIS и NIS+ (см. лекцию 19), если мы говорим о централизации. Кроме того, аутентификация может происходить по протоколу TACACS (широко распространен в серверах удаленного доступа Cisco) или RADIUS (в серверах удаленного доступа Nortel). Бывают и другие возможности аутентификации. Единого общепринятого механизма, который давал бы общий интерфейс аутентификации для любой сетевой службы и любого способа аутентификации, пока не существует, хотя с течением времени появляются новые стандарты, претендующие на эту роль.
Структура подсистемы PAM - присоединяемых модулей аутентификации
Новая модель аутентификации - присоединяемые модули аутентификации (PAM, Pluggable Authentication Modules) - была предложена в 1995 году сотрудниками SunSoft Самаром (V. Samar) и Шемерсом (R. Schemers). Эта модель предполагала, что любое приложение будет работать со стандартным интерфейсом аутентификации, а механизм аутентификации сможет быть различным - для аутентификации в разных базах данных пользователей (NIS, TACACS, файлах /etc/passwd и /etc/shadow, контроллерах домена Microsoft Windows и т.п.). Более того, предполагалось, что системный администратор должен иметь возможность выбрать, какой вид аутентификации будет использоваться в системе по умолчанию и/или для каждой из служб в отдельности: от ввода текстового пароля до биометрической проверки и использования смарт-карт.
Возможность индивидуальной настройки аутентификации для каждого из приложений, требующих ее, - это большой шаг вперед к гибкой настройке системы. Например, все базовые службы можно аутентифицировать по умолчанию, через ввод пароля, а что-то нестандартное или особо секретное (доступ к настройкам фильтра пакетов, например) - специальным образом.
В PAM с каждым приложением можно связать не один, а несколько механизмов аутентификации, например, потребовать от пользователей аутентифицироваться и через Kerberos, и через RSA.
Общий интерфейс системы аутентификации для всех приложений означает, что системные подпрограммы, полагающиеся на систему аутентификации, не зависят от изменений этой системы.
Архитектура PAM - модульная, и позволяет добавить любой модуль с поддержкой какого угодно алгоритма аутентификации, но при этом для обратной совместимости PAM API поддерживает ранее существовавшие вызовы подпрограмм аутентификации.
Добавление PAM в Solaris не означает, что системный администратор обязан специальным образом настраивать систему аутентификации, PAM лишь предоставляет такую возможность. Если нет желания переделывать настройки по умолчанию, то для пользователей все останется, как было раньше. А системный администратор будет помнить, что каталог /etc/pam.d, в котором хранятся настройки PAM, трогать не следует.

Модули PAM

Механизм аутентификации PAM основан на модулях аутентификации. Сейчас можно уже называть его отраслевым стандартом, так как PAM поддерживается в Linux, FreeBSD, Solaris и HP-UX, а также в ряде других менее распространенных систем UNIX.
Со стороны приложения PAM предоставляет API для обращения к функциям аутентификации.
Программа (login, su, ftp, httpd и т.п.) вызывает функцию PAM API в ситуации, требующей провести аутентификацию. С другой стороны (со стороны модуля аутентификации), PAM располагает интерфейсом SPI (Service Provider Interface), через который вызов API транслируется к источнику аутентификации (файлу /etc/passwd, серверу TACACS и т.п.).
API является общим для всех программ, а SPI содержит по одному модулю на каждый вариант аутентификации (один - через /etc/passwd, другой - через Kerberos и т.п.).
С помощью PAM системный администратор может установить свой способ аутентификации для любой сетевой службы. Более того, спектр способов весьма широк. Наиболее впечатляющей, на мой взгляд, является возможность аутентификации через базу данных о пользователях любого домена Windows NT или Windows 2000.
Самой важной возможностью PAM является гибкость настройки аутентификации. Системный администратор может указать любой способ аутентификации для любой программы. Правда, при этом необходимо, чтобы программа поддерживала аутентификацию через PAM. Например, web-сервер может не уметь работать с PAM. Однако Apache умеет это делать, хотя для этого требуется загружать отдельный модуль Apache.
В Solaris настройки PAM хранятся в файле /etc/pam.conf. Во многих других системах UNIX допускается также хранение настроек в каталоге /etc/pam.d/. Если такой каталог существует, то подпрограммы PAM игнорируют содержимое /etc/pam.conf.
Аутентификацию через PAM используют программы login, passwd, su, rlogind, rshd, telnetd, ftpd, rpc.rexd, uucpd, init, sac, cron, ppp, dtsession, ssh и ttymon. Программа dtlogin, которая является службой входа в сеть в графической среде Common Desktop Environment (CDE), тоже использует PAM.
Модули PAM могут располагаться в любых каталогах, однако негласное правило требует, чтобы файл имел имя, начинающееся с pam, pam_modulename.so.x, например pam_smb_auth.so.6, и хранился в подкаталогах каталога /usr/lib/security/.

Функции модулей PAM

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

  • управление учетными записями;
  • управление аутентификацией;
  • управление паролями;
  • управление сессиями.

Для идентификации этих задач в конфигурационном файле используются аббревиатуры account, auth, password, session.
Решение одной или нескольких из этих задач требуется при доступе пользователя к ресурсу.
Какие цели у модуля, решающего ту или иную задачу?
account - описывает службу проверки учетной записи, которая отвечает на вопросы: "есть ли такая запись и не истек ли срок действия пароля? имеет ли пользователь право доступа к запрошенному ресурсу?"
authentication - описывает службу проверки идентичности пользователя. Эта служба реализована посредством диалога между пользователем и программой аутентификации: "как тебя зовут и какой у тебя пароль?" Здесь пользователь обязан сообщить соответствующие друг другу имя и пароль (или иное подтверждение того, что пользователь именно тот, за кого он себя выдает).
Некоторые методы аутентификации (например, смарт-карты) не предполагают диалога, идентификацию выполняет специальная аппаратура, которая общается с написанным специально для нее модулем PAM. В этом проявляется гибкость PAM: старый добрый login может не задавать вопросов "login:", "password:".
Не меняя программ, требующих аутентификацию, PAM позволяет аутентифицировать пользователя любым способом, который изберет системный администратор. Может быть сейчас он еще и не знает, что он выберет через год, а кто-то уже пишет PAM-модуль для своей аппаратуры опознавания сотрудника по запаху.
password - описывает службу изменения пароля; такая служба должна быть тесно связана со службой проверки учетной записи. Например, по истечении срока действия пароля система требует у пользователя новый пароль.
session - описывает работы, которые должны быть выполнены до того, как ресурс будет предоставлен, или после того, как он будет освобожден (например, после разрыва соединения между программой-клиентом и вызванной им службой-сервером). Это может быть протоколирование начала и конца соединения, монтирование домашнего каталога пользователя и т.п.

Настройка доступа к некоторым службам через PAM
Конфигурационный файл /etc/pam.conf определяет соответствие между приложением и PAM-модулями, которые выполняют аутентификацию.
При обращении приложения к PAM для аутентификации, происходит инициализация соединения приложения с PAM API. При этом читается файл конфигурации /etc/pam.conf.
Файл конфигурации содержит список модулей PAM, которые будут использоваться для аутентификации. Рассмотрим файл конфигурации /etc/pam.conf:
#
#ident "@(#)pam.conf 1.20 02/01/23 SMI"
#
# Copyright 1996-2002 Sun Microsystems, Inc. All rights
# reserved. Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e.,
# they are relative to /usr/lib/security/$ISA.
# Absolute path names, as present in this file in previous
# releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_auth.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for
# authenctication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_auth.so.1
#
# passwd command (explicit because of a different
# authentication module)
#
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of
# pam_roles.so.1)
#
cron account required pam_projects.so.1
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for
# account management
#
other account requisite pam_roles.so.1
other account required pam_projects.so.1
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for
# session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for
# password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication
# (uncomment to use Kerberos)
#
#rlogin auth optional pam_krb5.so.1 try_first_pass
#login auth optional pam_krb5.so.1 try_first_pass
#other auth optional pam_krb5.so.1 try_first_pass
#cron account optional pam_krb5.so.1
#other account optional pam_krb5.so.1
#other session optional pam_krb5.so.1
#other password optional pam_krb5.so.1 try_first_pass

Файл /etc/pam.conf состоит из правил - по одному правилу в строке. Если правило не помещается на одну строку, то в ее конце следует поставить символ "\", для экранирования следующего за ним перевода строки.
Комментарии начинаются знаком "#" и продолжаются до конца строки (обратите внимание на то, что в вышеприведенном файле, поставляющемся по умолчанию, конфигурация Kerberos закомментирована).
Каждое правило состоит из пяти полей, которые отделяются друг от друга пробелами, первые три поля нечувствительны к регистру букв:
приложение задача управление путь/к/модулю аргументы_вызова_модуля

Имя приложения other зарезервировано для указания модулей аутентификации по умолчанию, то есть для тех приложений, о которых в файле конфигурации ничего не сказано явным образом.
Несколько правил могут быть организованы в стек для последовательной аутентификации несколькими PAM-модулями. Поле "задача" характеризует ту задачу, которая решается модулем. Это может быть account, auth, password или session.
"Управление" определяет поведение PAM в случае, если модуль примет решение об отказе в аутентификации1) (допустим, сочтет пароль неверным). Возможные варианты действий:

  • requisite - отказ приводит к немедленному прекращению аутентификации;
  • required - отказ приводит к тому, что PAM API возвращает ошибку, но только после того, как будут вызваны все оставшиеся в стеке модули (для этого приложения);
  • sufficient - успешная аутентификация достаточна для удовлетворения требований по аутентификации стека модулей (если предыдущий модуль в стеке выдал отказ в аутентификации, то успех аутентификации текущего модуля игнорируется);
  • optional - успех или отказ в аутентификации с использованием данного модуля имеет значение, только если это единственный модуль в стеке, ассоциированном с данным приложением и типом аутентификации (т.е. нет других optional модулей).

Путь к модулю - полное имя файла PAM-модуля для вызова приложением.
Аргументы модуля - разделенные пробелами аргументы, которые могут использоваться для изменения поведения модуля. Могут быть у любого модуля и определяются в документации на конкретный модуль.
Некоторые модули ограничиваются только поддержкой задачи auth. В то же время ряд приложений требуют не только этого при выполнении аутентификации, но и выполнения задачи account. Тогда приходится подставлять для выполнения второй задачи модуль pam_permit.so, который все разрешает без проверки. Если указать только одну задачу (auth), аутентификация может не заработать вообще, если приложение так устроено.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика