Linux pam что это

Обновлено: 03.07.2024

Если вы увлекаетесь британским детективом и знаете, кто такие Шерлок Холмс, Секстон Блейк, мистер Ридер, мисс Марпл, Эркюль Пуаро, Отец Браун, доктор Джон Эвелин Торндайк и лорд Питер Уимсли, тогда вы наверняка знаете персонажа, придуманного Э.У. Хорнунгом (это зять сэра Артура Конан-Дойля, создателя Шерлока Холмса) - джентльмен-вор Раффлс. В рассказе "Подарок к юбилею" он был очарован старинной золотой чашей, выставленной в Британском музее. Найдя единственного охранника, Раффлс расспрашивает его о его службе, и получает самонадеянный ответ: "Видите ли, сэр, сейчас еще рано, однако днем здесь будет полно народу, и чем больше людей, тем безопаснее." (пер. А. Егорова). В операционной системе Linux безопасность обеспечивается не количеством глаз (которое как раз не спасло беднягу-охранника; в конце статьи можно найти ссылку на текст рассказа), а с помощью PAM (Pluggable Authentication Modules, Подключаемых Модулей Аутентификации). В этой статье мы познакомимся с функциями, настройками и использованием PAM.

Давайте начнем с самого начала и рассмотрим, как программа аутентифицирует пользователя. Если не будет единого базового механизма аутентификации, тогда каждая программа должна содержать в себе логику аутентификации, такую как просмотр файла /etc/passwd на наличие пользователя и соответствия введенного пароля. Но что если таких программ много? Придется включать одну и ту же логику в каждую из них? А если требования к безопасности изменятся? Что, придется модифицировать и перекомпилировать все эти программы? Очевидно, это плохой метод и наверняка не самый безопасный. Как бы сделать так, чтобы все приложения сразу обновлялись до требуемого метода аутентификации и удовлетворяли новым требованиям безопасности?

Проект PAM предоставляет решение путем добавления дополнительного программного уровня. Программа, которой требуется аутентификация, должна использовать стандартную библиотеку или API (Application Programming Interface, Прикладной программный интерфейс), а системный администратор должен указать порядок аутентификации для данной конкретной программы (проверки осуществляются отдельными модулями; можно даже запрограммировать собственные модули). Таким образом, можно динамически изменять требования безопасности, причем все программы будут автоматически следовать вашим новым указаниям. Другими словами, можно модифицировать механизмы аутентификации программ (которые собраны с поддержкой PAM) без пересборки самих программ. С точки зрения программиста это очень хороший подход, ведь ему не требуется связываться с механизмами аутентификации. Когда мы используем модули PAM, требуемые проверки выполняются автоматически (см. рисунок 1).

Библиотека PAM разбивает механизм аутентификации на четыре группы (см. таблицу 1). Обратите внимание, что не всем программам требуются все четыре действия. К примеру, команде passwd требуется лишь последняя группа. Подсказка: как определить, использует ли программа PAM? Нужно вывести с помощью утилиты ldd все разделяемые библиотеки, используемые данной программой, и найти среди них libpam.so; пример см. в листинге 1.

Рисунок 1. Когда программа делает запрос аутентификации, библиотека PAM исполняет код модулей, указанных в конфигурационном файле и принимает решение, принять (успех) или отклонить (неудача) этот запрос.

Листинг 1. Чтобы узнать, использует ли программа PAM, воспользуйтесь утилитой ldd и найдите в ее выводе библиотеку libpam.so. Нужно писать полный путь до исполняемого файла. Если не знаете полный путь, узнайте его с помощью команды whereis. Например:

Таблица 1. Проверки PAM подразделяются на четыре группы, организованных в виде очереди. Задействование тех или иных групп определяется запросами пользователя.

auth	Относится к аутентификации пользователей, к примеру, когда нужно ввести пароль. Обычно эти проверки идут первыми.
account	Относится к управлению учетными записями, к примеру, сюда входит проверка устаревания пароля и проверки по времени доступа. Когда пользователь идентифицирован с помощью модулей auth, модули account определяют, можно ли пользователю давать доступ.
session	Относится к управлению соединениями, например, журналирование входов в систему, журналирование выполненных действий или выполнение очистки по завершению сессии.
password	Содержит функции, например, обновление пароля пользователя.

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

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

Настройка PAM

Для каждой службы (такой как login или SSH), необходимо указать, какие проверки будут сделаны в каждой группе. Список этих действий называется стеком. В завимости от результата исполнения в каждом стеке, пользователю будет разрешен или отклонен доступ, либо что-то будет позволено или не позволено. Исполняемые действия задаются для каждой службы в отдельном файле в каталоге /etc/pam.d (новый метод), либо в едином файле /etc/pam.conf (старый метод). В данной статье рассмотрен первый, новый метод.

Внимание! Помните, что безрассудная правка конфигурационных файлов может сделать вашу систему неработоспособной! К примеру, удалив все конфигурационные файлы, вы не сможете вновь войти в систему. Поэтому убедитесь, что у вас под рукой есть резервная копия всех конфигов и загрузочный CD.

Управляющие флаги могут быть и более сложными, но я не стану перечислять их все. Если интересно, в конце статьи есть ссылка на подробности. Также можно использовать директиву include, к примеру auth include common-account , которая включает содержимое (а именно правила) других файлов.

Существует особый сервис под названием other, который используется в тех случаях, когда для программы, использующей PAM, не найдено соответствующего конфигурационного файла. С точки зрения безопасности будет неплохо начать с создания /etc/pam.d/other такого, как на листинге 2. Все попытки войти в систему будут отклонены, а администратору будет отправлено уведомление об этом событии. Если хотите сделать более либеральные правила, замените pam_deny.so на pam_unix2.so, тогда будет использоваться стандартный метод аутентификации Linux, хотя уведомление все равно будет отправлено (см. листинг 3). Если не заботиться о безопасности, замените pam_deny.so на pam_permit.so - это даст доступ для всех, но потом пеняйте на себя.

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

Листинг 2. Безопасные правила "other" отклоняют все запросы доступа к службе, для которой не указаны другие правила. Модуль pam_deny.so всегда завершается неудачей, поэтому все попытки получения доступа будут отклонены, вдобавок к этому модуль pam_warn.so отправит системному администратору уведомление об этом событии.

Листинг 3. Правила PAM, эквивалентные стандартным правилам безопасности UNIX. Замечание: в некоторых дистрибутивах нужно указывать модуль pam_unix.so.

Листинг 4. Файл /etc/pam.d/sshd содержит правила безопасности для SSH-соединений. Обратите внимание, что модуль pam_access.so добавляет дополнительные проверки (см. листинг 5).

Листинг 5. Файл /etc/security/access.conf используется модулем pam_access.so, чтобы определить, каким пользователям позволено входить в систему и с каких IP-адресов. В данном примере, в систему теоретически может войти любой пользователь локальной сети, но лишь пользователю remoteKereki позволен удаленный доступ извне.

Листинг 6. Секция password в файле /etc/pam.d/passwd определяет хорошие требования, предъявляемые к новым паролям.

Безопасный удаленный доступ

pam_unix2.so: предоставляет традиционные методы по работе с паролями, правами и сессиями, классический UNIX-подход.
pam_nologin.so: запрещает вход в систему, когда существует файл /etc/nologin.
pam_access.so: реализует дополнительные правила контроля доступа (будет описано чуть позже), в соответствии с файлом /etc/security/access.conf.
pam_limits.so: накладывает ограничения на пользователей и группы, в соответствии с файлом /etc/security/limits.conf.
pam_umask.so: устанавливает маску создания файла для текущего окружения (более подробные сведения дает команда info umask).
pam_pwcheck: проверяет прочность пароля (подробности также будут даны чуть позже).

Если вы взглянете на файл /etc/pam.d/sshd, который установлен в вашей системе, вы наверняка увидите то же самое, только не будет модуля pam_access. Он и представляет здесь наибольший интерес. Этот модуль обеспечивает дополнительные проверки, определяемые файлом /etc/security/access.conf. В нем я указал тех, кто может получать доступ к моему компьютеру (листинг 5). Первая строка определяет, что войти в систему может любой пользователь (ALL) из внутренней домашней сети. Вторая строка означает, что пользователь remoteKereki может войти в систему из любой точки мира, а последняя строка однозначно завершает политику доступа, запрещая доступ всем, кто не указан в предыдущих строках. Я создал пользователя remoteKereki с минимумом прав, чтобы я сам мог войти в систему, затем, выполнив su, стать собственно собой или пользователем root, если потребуется. Если злоумышленник угадает пароль для remoteKereki, это ему не поможет, ведь атакующему придется еще угадывать пароль для других, более полезных пользователей. Таким образом, пользователь remoteKereki является дополнительным барьером для злоумышленников.

Чтобы демон sshd задействовал PAM при аутентификации пользователей, нужно добавить строку UsePAM yes в файл конфигурации /etc/ssh/sshd_config, а затем перезапустить SSH: /etc/init.d/sshd restart . Чтобы еще больше увеличить защищенность компьютера, можно перенести службу SSH со стандартного порта (22) на другой, запретить вход в систему под именем root и ограничить число попыток входа, чтобы усложнить задачу брут-форса (прямого перебора всех паролей), как это сделать - тема отдельной статьи. Дополнительные сведения можно получить в руководстве man sshd_config.

Нужны хорошие пароли

Какова длина нового пароля?
Похож ли новый пароль на бывший?
Совпадает ли новый пароль со старым, или записан как зеркальное отображение старого, или получен перестановкой частей старого пароля? (к примеру, safe123 и 123safe)
Новый пароль получен изменением регистра некоторых букв старого пароля? (например, sEcReT и SEcrET)
Использовался ли этот пароль ранее? (старые пароли сохраняются в файле /etc/security/opasswd)

Можно вызвать модуль с параметрами (их полный перечень смотри в man pam_pwcheck), которые описывают дополнительные правила:

minlen=aNumber: определяет минимальную длину (по умолчанию, 5 символов) нового пароля. Значение "нуль" означает, что будет принят любой пароль.
cracklib=pathToDictionaries: проверяет новый пароль на наличие в словаре cracklib. Если пароль имеется в словаре, тогда самая простая брут-форс атака легко и быстро взломает его.
tries=aNumber: определяет количество попыток смены пароля, ведь новый пароль может быть не принят из-за его простоты.
remember=aNumber: определяет количество запоминаемых предыдущих паролей.

Сходную функциональность предоставляет другой модуль, под названием pam_cracklib.so, однако у него другие параметры. К примеру, в нем можно указать, в скольких символах должны отличаться старый и новый пароли, нужно ли включать цифры, символы в верхнем и нижнем регистрах, а также неалфавитные символы. Более подробную информацию можно найти в руководстве man pam_cracklib.

Заключение

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

Модули, модули кругом

Безопасность вашей системы зависит от используемых вами модулей. Модули хранятся в каталоге /lib/security или /lib64/security (для 64-битных систем), однако некоторые дистрибутивы не следуют этому стандарту. К примеру, в некоторых системах модули можно найти в каталоге /usr/lib/security. При желании можно написать и собственные модули (см. раздел Источники информации), но для начала следует разобраться с уже имеющимися. Ниже приведен список наиболее часто используемых модулей. Больше информации по каждому из них можно получить, набрав man модуль , к примеру man pam_pwcheck . Обратите внимание, что нет "стандартного списка" модулей. Их состав варьируется от дистрибутива к дистрибутиву.

Источники информации

Федерико Кереки (Federico Kereki) - системный инженер из Уругвая, в течение 20 лет преподает в университете, работает разработчиком и консультантом, пишет статьи и учебные курсы. Он пользуется Linux уже много лет. Заинтересован в улучшении безопасности и производительности Linux-машин.

Мануал

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

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

Многие современные дистрибутивы Linux по умолчанию поддерживают Linux-PAM (в дальнейшем именуемый «PAM»).

В этой статье мы расскажем, как настроить расширенный PAM в системах Ubuntu и CentOS.

Прежде чем мы продолжим, обратите внимание, что:

Вам не обязательно понимать внутреннюю работу PAM.

PAM может серьезно изменить безопасность вашей системы Linux.

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

Например, случайное удаление файла (ов) конфигурации в /etc/pam.d/* и / или /etc/pam.conf может заблокировать вас в вашей собственной системе!

Как проверить программу на работу с PAM

Чтобы использовать PAM, приложение / программа должны быть «осведомлены о PAM»; он должен быть написан и скомпилирован специально для использования PAM.

Чтобы узнать, является ли программа «осведомленной о PAM» или нет, проверьте, скомпилирована ли она с библиотекой PAM с помощью команды ldd.

Как настроить PAM в Linux

PAM будет игнорировать файл, если каталог существует.

Синтаксис основного файла конфигурации выглядит следующим образом.

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

Мы объясним эти токены в следующих разделах.

service: фактическое название приложения.
type: тип модуля / контекст / интерфейс.
control-flag: указывает на поведение PAM-API, если модуль не может выполнить свою задачу аутентификации.
module: абсолютное имя файла или относительный путь PAM.
module-argumetns: список токенов для управления поведением модуля.

Синтаксис каждого файла в /etc/pam.d/ аналогичен синтаксису основного файла и состоит из строк следующего вида:

Это пример определения правила (без аргументов модуля), найденного в файле /etc/pam.d/sshd, который запрещает вход без полномочий root при наличии /etc/nologin:

Понимание групп управления PAM и контрольных флагов

Задачи аутентификации PAM разделены на четыре независимые группы управления.

Эти группы управляют различными аспектами типичного запроса пользователя на ограниченный сервис.

Модуль связан с одним из этих типов групп управления:

account: предоставлять услуги для проверки учетной записи: срок действия пароля пользователя истек ?; разрешен ли этому пользователю доступ к запрашиваемой услуге?
authentication: аутентификация пользователя и настройка учетных данных пользователя.
password: отвечают за обновление пользовательских паролей и работают вместе с модулями аутентификации.
session: управление действиями, выполненными в начале сеанса и в конце сеанса.

Загружаемые объектные файлы PAM (модули) должны находиться в следующем каталоге: /lib/security / или /lib64/security в зависимости от архитектуры.

Поддерживаемые флаги управления:

Как ограничить root-доступ к SSH-сервису через PAM

В качестве примера, мы настроим, как использовать PAM для отключения доступа пользователя root к системе через SSH и программы входа в систему.

Здесь мы хотим отключить доступ пользователя root к системе, ограничив доступ к службам входа и sshd.

Мы можем использовать модуль /lib/security/pam_listfile.so, который предлагает большую гибкость в ограничении привилегий определенных учетных записей.

Откройте и отредактируйте файл для целевой службы в каталоге /etc/pam.d/, как показано ниже:

Добавьте это правило в оба файла.

Объяснение токенов в приведенном выше правиле:

auth: тип модуля (или контекст).
required: это управляющий флаг, который означает, что если модуль используется, он должен пройти, иначе общий результат будет неудачным, независимо от состояния других модулей.
pam_listfile.so: это модуль, который предоставляет способ запретить или разрешить услуги на основе произвольного файла.
onerr = успешно: аргумент модуля.
item = user: module аргумент, который указывает, что указано в файле и должно быть проверено.
sense = deny: аргумент модуля, который определяет действие, которое нужно предпринять, если оно найдено в файле, если элемент НЕ найден в файле, то запрашивается противоположное действие.
file = /etc/ssh/deniedusers: аргумент модуля, который указывает файл, содержащий один элемент в строке.

Далее нам нужно создать файл /etc/ssh/ deniedusers и добавить в него имя root:

Сохраните изменения и закройте файл, затем установите для него необходимые разрешения:

Отныне вышеприведенное правило будет указывать PAM обратиться к файлу /etc/ssh/deniedusers и запретить доступ к SSH и службам входа для любого пользователя в списке.

Резюме

Это мощный, но очень сложный для понимания и использования.

В этой статье мы объяснили, как настроить расширенные функции PAM в Ubuntu и CentOS

. Если у вас есть какие-либо вопросы или комментарии, используйте форму обратной связи ниже.

В этой статье мне бы хотелось рассказать о том, как приложения в Linux могут использовать систему Подключаемых Модулей Безопасности (Pluggable Authentication Modules) для прозрачной аутентификации пользователей. Мы немного покопаемся в истории развития механизмов аутентификации в Linux, разберемся с системой настроек PAM и разберем исходный код модуля аутентификации pam_p11, который позволяет проводить аутентификацию пользователей по смарт-картам.
В конце статьи мы рассмотрим на практике настройку и работу модуля аутентификации в сертифицированном по 3 классу защищенности СВТ и 2 уровню контроля отсутствия недекларированных возможностей дистрибутиве Astra Linux для аутентификации по USB-токенам Рутокен ЭЦП и Рутокен S. Учитывая то, что Рутокен S имеет сертификаты ФСТЭК по НДВ 3, а Рутокен ЭЦП по НДВ 4, это решение может применяться в информационных системах, обрабатывающих конфиденциальную информацию, вплоть до информации с грифом «С».

Немного истории

Linux-PAM – основная реализация архитектуры PAM, рассматривается нами в этой статье
OpenPAM – альтернативная реализация PAM, используемая в BSD-системах и Mac OS X
Java PAM – Java-обертка над Linux-PAM

Структура PAM

Запросить пароль у пользователя и проверить введенное значение с хранимым в системе
Проверить, удовлетворяет ли пароль требованиям безопасности и не истек ли он

Приложение инициализирует библиотеку PAM (libpam.so)
PAM в соответствии с конфигурационным файлом для приложения обращается к требуемым модулям
Модули выполняют возложенные на них действия
Приложению возвращается результат операции

Аутентификация (auth)
Управление учетными записями (account)
Управление сеансами (session)
Управление паролями (passwd)

Конфигурация PAM

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

Для примера, посмотрим на абстрактный файл конфигурации для приложения login

Каждая строчка конфига записывается в виде

Тип модуля соответствует обозначениям самих модулей (т.е. auth/account/session/passwd)
Управляющий флаг указывает критичность модуля для успешного выполнения операции. Флаг может принимать следующие значения: requisite (необходимый), required (требуемый), sufficient (достаточный) и optional (необязательный).
Путь к библиотеке задает собственно путь до файла модуля. По умолчанию они ищутся в /lib/security/
Параметры задают список аргументов, которые будут переданы модулю. Аргументы передаются аналогично принципу argc/argv в функции main(), за исключением того, что argv[0] содержит не имя модуля, а конкретный аргумент.

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

Разработка модуля аутентификации для PAM

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

pam_p11

На токене хранится сертификат пользователя и его закрытый ключ
Сертификат также сохранен в домашнем каталоге пользователя как доверенный

На токене выполняется поиск сертификата пользователя
Через PAM производится запрос PIN-кода к токену
Если аутентификация на токене прошла успешно, то производится подпись случайных данных с помощью закрытого ключа с токена. Сама подпись выполняется аппаратно.
Полученная ЭЦП проверяется с помощью сертификата пользователя

Собственно разработка модуля

pam_sm_authenticate, pam_sm_setcred – аутентификация
pam_sm_acct_mgmt – управление учетными записями
pam_sm_chauthtok – управление паролями
pam_sm_open_session, pam_sm_close_session — управление сеансами

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

Запросим у PAM имя пользователя

Теперь среди сертификатов на токене найдем тот, что лежит у нас в

А сейчас самое интересное – нам нужно запросить через PAM пароль пользователя (который в нашем случае будет PIN-кодом к токену), а затем выполнить аутентификацию на токене

Теперь мы можем выполнить аутентификацию на токене:

На этом завершается первый этап аутентификации. Теперь нам нужно проверить, обладает ли владелец токена закрытым ключом. Для этого вычислим ЭЦП для произвольного блока данных и проверим ее с помощью доверенного сертификата.
Для начала считаем 128 байт из /dev/random

Затем получим закрытый ключ, соответствующий сертификату и подпишем на нем случайные данные

Проверим подпись. Для этого сначала средствами OpenSSL получим открытый ключ из сертификата, а затем выполним проверку ЭЦП

Вместо остальных функций оставим никому не интересные заглушки, соберем модуль и приступим к его настройке и использованию.

Практическое использование

В качестве подопытного дистрибутива можно было бы взять свежую Ubuntu, но учитывая то, что в 12.04 все слишком хорошо работает, мы решили с пользой для общего дела настроить аутентификацию в релизе «Смоленск» операционной системы Astra Linux Special Edition по USB-токенам Рутокен ЭЦП и Рутокен S.

Установка дополнительных пакетов

libopenct1 (0.6.20-1.2): libopenct1_0.6.20-1.2_amd64.deb
openct (0.6.20-1.2): openct_0.6.20-1.2_amd64.deb

Для Рутокен S

libopensc2_0.11.13-1.1_amd64.deb
opensc_0.11.13-1.1_amd64.deb
mozilla-opensc_0.11.13-1.1_amd64.deb

Для Рутокен ЭЦП

opensc (0.12.2-2): opensc_0.12.2-2_amd64.deb

libltdl7 (>= 2.2.6b): libltdl7_2.2.6b-2_amd64.deb
libssl0.9.8 (>= 0.9.8m-1): libssl0.9.8_0.9.8o-4squeeze11_amd64.deb

Модуль PAM и его зависимости

Настройка pam_p11

В появившемся диалоге необходимо выбрать pam_p11. Если вы хотите отключить аутентификацию по паролям, то можно отключить Unix authentication. Поскольку в конфигурационном файле профиля было указано, что модуль будет «sufficient», то при получении от нашего модуля ответа «PAM_SUCCESS» весь процесс аутентификации будет считаться успешным.

Создание ключа и сертификата

Для начала создаем ключевую пару RSA длины 2048 бит c ID «45» (id стоит запомнить, он понадобится при создании сертификата).

Проверим сгенерированный ключ:

Теперь с помощью OpenSSL создадим самоподписанный сертификат. Запускаем openssl и подгружаем модуль поддержки pkcs11:

Создаем сертификат в PEM-формате:

В последней команде 1:45 — это пара :<id ключа>. Таким образом, мы создали сертификат на базе ключевой пары, хранящейся на токене. При этом в текущем каталоге должен создаться файл сертификата с именем cert.pem.
Теперь сохраним сертификат на токен:

Занесение сертификата в список доверенных

На данном этапе нам осталось только прочитать с токена сертификат с нужным ID и записать его в файл доверенных сертификатов:

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.

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

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

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

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

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

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

Модули PAM.

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

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

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

Прежде, чем кто-либо получит доступ к 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:

Четыре типа флагов, стандартных для 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 файл приложения может выглядеть так:

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:

Первое. Если существует файл /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
Перевод:
Александр Шепетко

Читайте также: