Вход для зарегистрированных пользователей
логин
пароль
регистрация
забыли пароль?
Еще не зарегистрировались?

Дайджест

07 ноября 2017
Стороны договорились о реализации поддержки работы с устройствами Рутокен в решениях на платформе UserGate. Растущая сфера …
25 октября 2017
Атака "Badrabbit" стала одной из самых крупных за последние несколько месяцев. Данный троян-шифровальщик похож на …
24 октября 2017
Фирма «АНКАД» получила патент на изобретение «Компьютерная система с удаленным управлением сервером и устройством создания …
Контур-Фокус – быстрая проверка контрагентов

Актив

Разработка и производство программно-аппаратных средств обеспечения информационной безопасности.
Тел.: +7 (495) 925-77-90
E-mail: info@rutoken.ru
Контактная информация: О компании
Регионы работы: Москва
Статья

Разработка и применение модуля PAM для аутентификации в Astra Linux c использованием Рутокен ЭЦП и Рутокен S

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

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

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

Изначально в Linux, если приложению требовалось запросить аутентификацию пользователя, то ему приходилось обращаться к файлам /etc/passwd и(или) /etc/shadow. Такой подход весьма прост, но при этом разработчикам приходилось думать не только о работе с файлами, но и о вопросах безопасности. В связи с этим возникла необходимость разработки прозрачного механизма аутентификации пользователей, не зависящего от способа хранения информации об их учетных записях.

Решением тому стал проект Linux-PAM. К слову сказать, сама архитектура PAM была впервые предложена компанией Sun в октябре 1995 года, а в августе 1996 года инфраструктура Linux-PAM была включена в дистрибутив Red Hat Linux. В настоящее время существуют три основных реализации PAM:

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

Структура PAM

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

Нас же интересует, что же такое «Модуль PAM». Модули представляют собой библиотеки, в которых прописаны обработчики операций, которые может направлять к ним подсистема PAM. Для примера стандартный модуль pam_unix умеет следующее:

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

Ниже представлена общая схема работы PAM:

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

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

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

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

Сейчас нам интересна только аутентификация, поэтому рассмотрение остальных функций оставим любопытству читателя.

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

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

1
2
3
$ ls /etc/pam.d/
atd common-account common-session-noninteractive lightdm other samba vmtoolsd chfn common-auth cron lightdm-autologin
passwd sshd chpasswd common-password cups login polkit-1 su chsh common-session gnome-screensaver newusers ppp sudo

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

1
2
3
4
5
6
7
8
9
# PAM configuration for login
auth requisite pam_securetty.so
auth required pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
session optional pam_lastlog.so
password required pam_unix.so nullok obscure min=4 max=8

Каждая строчка конфигурации записывается в виде: <тип модуля> <управляющий флаг> <путь к библиотеке> <параметры>

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

Таким образом, мы получаем стек модулей, каждый из которых выполняет свое действие. PAM при этом разбирает стек как и положено – сверху вниз. В соответствии с управляющим флагом задаются следующие требования к успешности операции:

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

Конфигурационные файлы модулей хранятся в /usr/share/pam-configs/<имя модуля>. В каждом файле указывается полное имя модуля, включен ли он по умолчанию, приоритет модуля и параметры аутентификации.

Схема работы модуля аутентификации для PAM pam_p11

Данный модуль позволяет осуществить двухфакторную аутентификацию пользователей по смарт-картам или USB-токенам с использованием ассиметричной криптографии. Рассмотрим общую схему его работы

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

Аутентификация происходит следующим образом:

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

Если в итоге проверка подписи осуществлена успешно, то модуль сообщает об успешно пройденной аутентификации.

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

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

Система PAM может использоваться в любом дистрибутиве GNU/Linux, а в этой статье мы рассмотрим использование USB-токенов Рутокен ЭЦП и Рутокен S для двухфакторной аутентификации в релизе «Смоленск» операционной системы Astra Linux Special Edition.

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

Для начала пришлось установить дополнительные пакеты. Для работы Рутокен S необходима старая версия OpenSC — 0.11.13, а для работы Рутокен ЭЦП – более новая: 0.12.2. В качестве middleware для обоих токенов используется OpenCT версии 0.6.20.

В итоге были поставлены пакеты, переданные разработчиками дистрибутива:

  • 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

При установке новой версии opensc потребовалось удовлетворить зависимости пакетов. Для этого были взяты следующие пакеты из репозитория Debian squeeze:

  • 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 и его зависимости

Для осуществления аутентификации по токену были установлены пакеты:

  • libp11-1 (0.2.7-2): libp11-1_0.2.7-2_amd64.deb
  • libpam-p11 (0.1.5-1): libpam-p11_0.1.5-1+b1_amd64.deb
  • libengine-pkcs11-openssl (0.1.8-2): libengine-pkcs11-openssl_0.1.8-2_amd64.deb

Настройка pam_p11

К счастью, нам не почти не придется править конфиги руками. Достаточно только создать файл /usr/share/pam-configs/p11 со следующим содержанием:

1
2
3
4
5
Name: Pam_p11
Default: yes
Priority: 800
Auth-Type: Primary
Auth: sufficient pam_p11_opensc.so /usr/lib/opensc-pkcs11.so

А затем выполнить команду pam-auth-update.

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

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

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

1
2
$ pkcs15-init --generate-key rsa/2048 --auth-id 02 --id 45
  <вводим PIN пользователя>

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

1
2
3
4
5
6
7
8
9
10
11
12
$ pkcs15-init --generate-key rsa/2048 --auth-id 02 --id 45
$ pkcs15-tool --list-keys
Using reader with a card: Aktiv Rutoken ECP 00 00
Private RSA Key [Private Key]
Object Flags : [0x3], private, modifiable
Usage : [0x4], sign Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref : 1 (0x1)
Native : yes
Path : 3f001000100060020001
Auth ID : 02
ID : 45

Теперь с помощью OpenSSL создадим самоподписанный сертификат.

Запускаем openssl и подгружаем модуль поддержки pkcs11:

1
2
3
4
5
6
7
8
$ openssl
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
Loaded: (pkcs11) pkcs11 engine

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

1
OpenSSL> req -engine pkcs11 -new -key 1:45 -keyform engine -x509 -out cert.pem -text

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

Теперь сохраним сертификат на токен:

1
2
$ pkcs15-init --store-certificate cert.pem --auth-id 02 --id 45 --format pem
<Вводим PIN пользователя>


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

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

1
2
3
4
5
mkdir ~/.eid
chmod 0755 ~/.eid
pkcs15-tool -r <certificate_id> > ~/.eid/authorized_certificates
chmod 0644 ~/.eid/authorized_certificates
</certificate_id>


Заключение

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

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

Автор: Кирилл Романовский


Поделись ссылочкой:


©   ООО «Инфосекьюрити»
Тел.: +7 (495) 231-4831   +7 (495) 778-4675Адрес:  Москва, Б.Семеновская, 49


PROFLINE - сайты на Битрикс