Какие типы модулей поддерживает pam astra linux

Какие типы модулей поддерживает pam astra linux

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

#%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow nullok use_authtok session required /lib/security/pam_unix.so

Первая строка является комментарием (любая строка, начинающаяся с ‘#’ — это комментарий. Строки со второй по четвертую используются для аутнетификации.

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
Перевод:
Александр Шепетко

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

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

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

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

Структура PAM

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

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

• Аутентификация (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

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

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

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

• 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. Она имеет следующую сигнатуру:

• pamh – хендл к PAM, полученный приложением
• argc, argv – аргументы, указанные в конфигурационном файле. Наш модуль принимает один аргумент – путь к библиотеке PKCS#11

• PAM_AUTH_ERR – ошибка аутентификации
• PAM_CRED_INSUFFICIENT – у приложения недостаточно прав для выполнения аутентификации
• PAM_AUTHINFO_UNAVAIL – модулю не удалось получить информацию для выполнения аутентификации. Это может случиться из-за проблем в сети или другого отказа оборудования
• PAM_SUCCESS – аутентификация прошла успешно
• PAM_USER_UNKNOWN – пользователь с переданным именем не существует
• PAM_MAXTRIES – один или несколько модулей аутентификации превысили допустимый предел попыток.

Затем проверим, передали ли нам путь к библиотеке PKCS#11

После чего инициализируем OpenSSL и контекст PKCS#11

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

Теперь загрузим библиотеку PKCS#11, найдем первый доступный токен и получим с него сертификаты

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

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

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

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

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

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

Если проверка подписи прошла успешно, то мы можем завершить работу с библиотекой PKCS#11 и вернуть PAM_SUCCESS.

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

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

В качестве подопытного дистрибутива можно было бы взять свежую 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 и его зависимости

• 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 со следующим содержанием:

Интерес предоставляет последняя строчка конфига, в которой мы указываем тип модуля, имя библиотеки и параметры, передаваемые модулю. Наш модуль принимает в качестве параметра путь к библиотеке PKCS#11.
Теперь нам осталось только выполнить команду

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

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

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

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

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

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

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

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

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

PAM (Pluggable Authentication module) Usage and Configuration in Linux : All about PAM to know.

Pluggable authentication module (PAM) provides a mechanism to incorporate multiple low-level authentication schemes into a high-level application programming interface (API).

Sun Microsystems introduced the concept of PAM in an Open Software Foundation RFC(Request for Comments) 86.0 dated October 1995.

Linux Pluggable Authentication Modules provides a feature to put various checks w.r.t authentication and user account validation.

PAM provides dynamic authentication & validation of user account support to provide secure access of applications and services in a Linux.

2. Various PAM Modules in Linux

In Linux, we have different PAM modules available. The most widely used and developed modules include the following:

a. Account modules :- Whether account is valid or not.
b. Authentication modules :- Verify user password and other identities.
c. Password modules :- Provides feature to updating password.
d. Session modules :- Actions to be performed at beginning or end of the session.

3. PAM Configuration in Linux

PAM configuration either resides in /etc/pam.conf or in /etc/pam.d/ directory.
If /etc/pam.d directory exists, then /etc/pam.conf file is ignored.

4. PAM log file

Usually PAM logs are saved in /var/log/secure file. However we advise to look for “pam” keyword in all logs.

5. Understanding PAM Configuration File.

Lets have a look at /etc/pam.d/login file to understand it.

In above configuration file, lets take one entry to understand.
type control module-path module-arguments
session required pam_selinux.so close

a. type:- session type PAM module is called.
b. control:- If its required, or optional, or we need to include it.
c. Module-path: It determines the path where this module is kept. Simply module name means module is kept in PAM modules directory.
d. Options:- If any options need to be passed to the module, we provide it here.

6. How PAM configuration linked to services in Linux ?

Lets have a look how the configuration is attached with services in Linux.
The PAM configuration file name is same as that of service name or binary name.

7. How PAM shared objects are linked with binaries ?

Configuration Change Warning

8. Return Values of PAM Modules

In general a PAM module returns any of the following as return value.
a. PAM_SUCCESS : Access granted.
b. PAM_PERM_DENIED : Access not granted.
c. PAM_IGNORE : Ignore and do nothing.
d. PAM_ABORT : Abort due to less information.
e. PAM_USER_UNKNOWN : User not known.

There is a lot more in PAM, each and every module has different implementation and each of it needs to be studied to understand it better.

Какие типы модулей поддерживает pam astra linux

1 . Мандатный контроль целостности

В настоящее время большинство успешных взломов ОС реализуются с применением программных закладок.

Программная закладка — это небольшая по объёму кода программа, которая скрытно внедряется в атакуемую систему и предоставляют нарушителю скрытный доступ к ресурсам атакуемой ОС, вносит уязвимость в её подсистему безопасности, противодействуют антивирусному ПО, пакетным фильтрам, системам обнаружения атак и т. д. Компьютерные вирусы и сетевые черви являются частными случаями программных закладок.

Степень уязвимости ОС в отношении программных закладок в основном определяется двумя взаимосвязанными факторами:

• насколько легко программной закладке внедрить свой программный код в критически важные (например, системные) области атакуемой ОС;
• насколько большие полномочия может получить внедрённая в ОС программная закладка в практически значимых ситуациях.

Мандатный контроль целостности (Mandatory Integrity Control — MIC) в основном предназначен для того, чтобы затруднить программным закладкам внедрение в защищаемую ОС и дальнейшее функционирование в ней. В качестве побочного эффекта нейтрализуется угроза вывода ОС из строя некорректно работающим инсталлятором или деинсталлятором прикладного или системного ПО, ненамеренно повреждающим критически важные программные модули ОС.

Как правило, при реализации в ОС мандатного контроля целостности её сущности разделяются на несколько уровней целостности (в ОССН реализованы два уровня целостности: «Низкий» и «Высокий»), чем выше уровень целостности сущности, тем более важна данная сущность для обеспечения корректного функционирования ОС, и тем выше требования доверия к процессу, модифицирующему данную сущность.

Мандатный контроль целостности, как это формально определено в рамках МРОСЛ ДП-модели, не допускает модификации сущностей с высоким уровнем целостности недоверенными процессами с низким уровнем целостности.

МРОСЛ ДП-модель — мандатная сущностно-ролевая ДП-модель.

ДП-модель — модель логического управления доступом «Д» и информационными потоками «П».

Обращения процессов ОССН к сущностям, потенциально нарушающие их целостность (операции записи, перемещения или удаления, понимаемые в широком смысле вариантов их реализации), разрешаются только в том случае, когда уровень целостности процесса не уступает уровню целостности сущности, к которой он обращается. Другими словами, модификация низкоцелостным субъектом высокоцелостной сущности запрещается независимо от дискреционных или мандатных прав доступа процесса к сущности. Модификация сущностей ОССН, важных с точки зрения её безопасности, разрешается только доверенным процессам, выполняющимся от имени привилегированных учётных записей пользователей с высоким уровнем целостности. Для ограничения возможностей перемещения или удаления критически важных сущностей присваивается соответствующий уровень целостности контейнеру, содержащему такие сущности.

Процесс, выполняющийся на низком уровне целостности, не имеет возможности:

• получать доступ к процессам, выполняющимся на более высоких уровнях целостности, в том числе не может направлять управляющие сообщения их окнам;
• порождать процессы, выполняющиеся от имени другой учётной записи пользователя, с использованием механизмов su, sudo, suid/sgid;
• порождать процессы, выполняющиеся на высоком уровне целостности.

В начале сеанса работы с ОССН пользователь выбирает уровень целостности для корневого процесса своей пользовательской сессии. Если для сессии выбран низкий уровень целостности, то все процессы, выполняющиеся в ней, гарантированно выполняются на низком уровне целостности.

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

Заметим, впрочем, что низкий уровень целостности не ограничивает возможности ПО нарушителя по несанкционированному доступу к пользовательским данным, хранящимся и обрабатывающимся в ОССН. Если нарушитель имеет возможность многократно повторять внедрение программной закладки в атакуемую ОССН (например, эксплуатируя критическую уязвимость в её коде), наличие мандатного контроля целостности не создаёт нарушителю серьёзных затруднений, здесь защита от утечки конфиденциальных данных должна осуществляться с применением мандатного управления доступом.

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

В ОССН мандатный контроль целостности по умолчанию отключён — всем сущностям ОССН назначается низкий уровень целостности. Для включения мандатного контроля целостности необходимо отредактировать скрипт инициализации файловой системы /usr/sbin/pdp-init-fs.

Для использования мандатного контроля целостности необходимо модифицировать сценарий pdp-init-fs, установив в 1 значение переменной sysmaxilev и флаг ccnri для контейнеров с флагом ccnr, и выполнить сценарий или перезагрузку ОС.

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

Содержимое файла pdp-init-fs:

# Analyze command line options

if [ $# -gt 0 ]; then

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr,ehole» /tmp

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /dev

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr,ehole» /tmp

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /var/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /var/private/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /var/private/*

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /var/run/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /var/run/mount/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /var/spool/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr,ehole» /var/run/shm/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr,ehole» /var/mail/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /home/

/usr/sbin/pdpl-file «$sysmaxlbl:ccnr» /home/.pdp/

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

Команда pdpl-file изменяет мандатные атрибуты файлов ОС, которые включают мандатную метку и специальные мандатные атрибуты файла. Утилита pdpl-file доступна в том числе через символическую ссылку pdp-flbl;

pdpl-file [опции]…[уровень][:уровень целостности[:категория[:флаги]]] [файл]

-f, —silent, —quiet — Не выводить сообщений об ошибках

-v, —verbose — Выводить диагностические сообщения для каждого файла

-c, —changes — То же, что и —verbose, но сообщать только об изменениях

-R, —recursive — Применить рекурсивно

-h, —help — Вывести справку и выйти

—version — Вывести информацию о версии и выйти

Уровень и категория могут быть заданы именем или шестнадцатеричным значением.

pdpl-file -Rv Секретно:0:Категория_А /tmp

Данная команда рекурсивно для всех файлов каталога /tmp изменит уровень на Секретно и категорию на Категория_А (уровень и категория должны быть определены в системе).

Флаги могут быть заданы значением или именами через запятую:

• ccnr — неприменение метки конфиденциальности контейнера (каталога) при просмотре его содержимого;
• ccnri — неприменение уровня целостности контейнера (каталога) при просмотре его содержимого;
• ehole — игнорирование мандатных уровней и категорий при выполнении операций записи.

Флаги могут быть заданы одним из псевдонимов:

• CCNRA — псевдоним для сочетания ccnr и ccnri;
• ALL — псевдоним для сочетания всех возможных флагов (в настоящее время
• ccnr, ccnri и ehole).

pdpl-file 2:0:0:ccnr /tmp

2 . Управление доступом к объектам графической подсистемы

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

В ОС семейства Linux графический интерфейс реализуется с использованием клиент-серверной системы X Window System. Давно известно, что данная система небезопасна. Например, возможность похищения процессом X Window System конфиденциальных данных, принадлежащих другому процессу, впервые описана в 1994 г. Р. Браатеном (Bråthen, Roger, http://web.textfiles.com/hacking/x.security или http://yztm.ru/ccxwin).

В 2002 г. Дж. Фишер (работает в CIAC — U.S. Department of Energy’s Computer Incident Advisory Capability) сформулировал основные угрозы, которые процесс X Window System может представлять для других процессов:

• модификация параметров сессии;
• несанкционированное создание/уничтожение окон;
• перехват оконных событий;
• навязывание оконных событий.

Логично предположить, что за прошедшие годы перечисленные угрозы были повсеместно нейтрализованы, но на самом деле это не так. Во всех без исключения (кроме использованной в ОССН) исследованных сотрудниками АО «НПО РусБИТех» реализациях X Window System некоторые важные проверки, необходимые для управления доступом пользователей к элементам графической подсистемы ОС, реализованы некорректно либо не реализованы вообще. В результате непривилегированный процесс-нарушитель в ряде случаев может несанкционированно повышать свои полномочия (например, направляя в окна привилегированных процессов последовательности оконных событий, имитирующие действия пользователя), а также похищать конфиденциальные данные из окон других процессов (например, несанкционированно внедряя своё дочернее окно внутрь окна атакуемого процесса). В результате проведённых исследований было обнаружено несколько уязвимостей, каждая из которых может быть устранена добавлением в код X Window System проверок соответствующих условий, но для полного их устранения, а также устранения предпосылок к появлению новых подобных уязвимостей, нужна существенная переделка графической подсистемы. Важно отметить, что обнаруженные уязвимости носят концептуальный характер, для их устранения недостаточно внести точечные изменения в программный код X Window System, в исправлении нуждаются его базовые концепции.

Для того чтобы наглядно пояснить одну из многих проблем безопасности X Window System, рассмотрим знаменитую атаку Shatter, впервые применённую для ОС Microsoft Windows в 2002 г. В классической реализации данной атаки процесс-нарушитель отправляет в окно привилегированного процесса ОС сообщение о состоянии несуществующего таймера, обработчиком которого якобы является функция, которую нарушитель желает несанкционированно вызвать в контексте привилегированного процесса. Другая известная реализация атаки находит одно из невидимых системных окон, незаметно создававшихся на рабочем столе в ранних версиях ОС Microsoft Windows ХР, назначает этому окну клавиатурный фокус и имитирует нажатие клавиши F1. Открывается окно справки ОС, при этом обслуживающий его процесс winhlp32.exe запускается с полномочиями привилегированной учётной записи псевдопользователя SYSTEM. Затем в данное окно с помощью имитации перемещения файла из окна в окно (drag-n-drop) загружается заранее подготовленный файл справки, содержащий внешнюю ссылку на приложение нарушителя, по которой сразу имитируется активизация. В результате программный код, предоставленный нарушителем, начинает выполняться в контексте привилегированного процесса.

Атака Shatter основана на том, что в ОС Microsoft Windows 2003 и более ранних версиях окна двух разных процессов, размещённых на одном и том же рабочем столе, могли обмениваться сообщениями фактически без ограничений. В результате во многих практически значимых ситуациях непривилегированные процессы могли несанкционированно повышать свои полномочия, направляя специально подобранные последовательности сообщений окнам привилегированных процессов. Каждая конкретная последовательность сообщений, приводящая к несанкционированному повышению полномочий, связана с отдельной уязвимостью, которую чаще всего несложно устранить, но до тех пор, пока сохраняется сама возможность управления окном привилегированного процесса из непривилегированного процесса, говорить о безопасности графической подсистемы не приходится. Похожие уязвимости были обнаружены и в X Window System.

В ОС семейства Microsoft Windows данная проблема была в основном решена реализацией в ОС Microsoft Windows Vista мандатного контроля целостности, дополненного контролем учётных записей (User Account Control — UAC). При этом в программный код графической подсистемы ОС были включены несколько сотен дополнительных проверок, учитывающих мандатные уровни целостности процессов и сущностей при реализации самых разнообразных операций в графической подсистеме. Данный подход предъявляет повышенные требования к квалификации и аккуратности реализующих его программистов — достаточно всего лишь одной пропущенной проверки, чтобы в графической подсистеме появилась критическая уязвимость. Особенно трудно реализовать данный подход в ситуации, когда базовый функционал графической подсистемы не создан с нуля доверенным разработчиком, а взят из стороннего проекта, скудно документированного, не имеющего централизованной технической поддержки и продолжающего развиваться непонятным и непредсказуемым образом.

В ОССН, начиная с версии 1.4, реализуется другой подход, основанный на изоляции сущностей графической подсистемы, мандатные атрибуты которых отличаются от заданных по умолчанию, в особые сеансы, изолированные с точки зрения графической подсистемы от основного сеанса работы пользователя с ОССН. В обычном сеансе работы пользователя таких сущностей не создаётся, они могут создаваться только если пользователь запускает процессы с нестандартными мандатными атрибутами, используя графическую утилиту fly-run (рис.1) или консольную утилиту sumac.

Рис. 1. Окно утилиты «Выполнить команду» (fly-run)

Команда sumac используется для запуска процесса с заданными мандатными уровнем и категорией в отдельной графической сессии с использованием виртуального графического сервера Xephyr.

sumac [-h, —help] [-v, —version] [-l, —level=] [-c, —category=] [-i, —stdin=] [-o, —stdout=] [-e, —stderr=] [-x, —xauth] [command]

Пользователь может запускать процесс только в пределах разрешенных ему уровней и категорий.

Если указанный мандатный уровень выше текущего, т. е. происходит увеличение уровня, то переменные окружения наследуются от текущего процесса. Если происходит уменьшение мандатного уровня, то текущие переменные окружения сбрасываются, чтобы избежать утечки информации. Аналогично при порождении нового процесса закрываются все файловые дескрипторы, мандатная метка которых не совпадает с указанной в командной строке. В том числе закрываются stdin, stdout, stderr. Перенаправить стандартный ввод и вывод для нового процесса можно с помощью опций -i, -o, -e для stdin, stdout и stderr, соответственно.

ВНИМАНИЕ! Запуск процесса с понижением мандатного уровня или с сокращением набора мандатных категорий запрещен для предотвращения утечки информации на более низкие уровни секретности.

1. Запуск графического приложения xterm с мандатным уровнем 2

$ sumac -l 2 xterm

-l , —level= Запустить процесс с указанным мандатным уровнем

-c , —category= Запустить процесс с указанной мандатной категорией

-i , —stdin= Перенаправить stdin запущенного процесса в указанный файл

-o , —stdout= Перенаправить stdout запущенного процесса в указанный файл

-e , —stderr= Перенаправить stderr запущенного процесса в указанный файл

-x, —xauth Попытаться создать запись в .Xauthority. В случае неудачи прервать

-h, —help Вывести справку и выйти

-v, —version Вывести информацию о версии и выйти

Тогда при старте процесса автоматически открывается новый сеанс (в терминах X Windows System — создается дисплей), и когда запущенный процесс вызывает системную функцию XOpenDisplay, подключение перенаправляется на этот новый сеанс. Окно программы приобретает вид, как показано на рисунке, представленном ниже.

Рис. 1. Окно приложения, выполняющегося в изолированной среде.

Окно программы, выполняющейся в изолированной среде, отличается от обычных окон следующими особенностями:

• К концу заголовка окна дописана строка «в изолированной среде (ctrl+g для захвата мыши и клавиатуры)». Заметим, что для большинства приложений захват мыши и клавиатуры осуществляется при необходимости автоматически и не требует нажатия каких-либо особых клавиш;
• цветная рамка, окружающая окно, отличается цветом от рамок, окружающих другие окна (за исключением ситуации, когда приложение, выполняющееся в изолированной среде, отличается от других приложений только неиерархическими категориями, но не мандатным уровнем);
• каждое приложение, выполняющееся в изолированной среде, имеет свой собственный буфер обмена (clipboard), изолированный от основного буфера обмена, позволяющего пересылать данные между приложениями. Передача данных через буфер обмена за пределы изолированной среды невозможна, как и приём данных из-за пределов изолированной среды.

Для помещения графических приложений в изолированную среду используется утилита Xephyr, создающая в ОССН полнофункциональный Х-сервер и проецирующая его графический вывод в одно из окон, функционирующих на основном Х-сервере. Для графических приложений основного Х-сервера окно изолированной среды выглядит как монолитный графический образ. Получить внутреннюю структуру данного окна, используя XQueryTree и другие подобные системные вызовы основного Х-сервера, невозможно.

При запуске приложения в изолированной среде последовательно выполняются следующие действия:

• в основном сеансе работы пользователя, обслуживаемым основным Х-сервером ОССН, создаётся новое окно;
• создается Х-сервер Xephyr, его графический вывод перенаправляется в окно, созданное на предыдущем шаге;
• запускается новый экземпляр оконного менеджера fly-wm, его подключение к Х-серверу (XOpenDisplay) перенаправляется на Х-сервер Xephyr (это необходимо для корректного отображения заголовка окна приложения, корректной работы некоторых функций графического интерфейса);
• запускается целевое приложение, его подключение к Х-серверу перенаправляется на Х-сервер Xephyr.

Выполнение графических приложений в изолированной среде требует 40-50 Мб дополнительной оперативной памяти на каждое такое приложение. Для сравнения, процесс Libre Office, в котором открыт пустой текстовый документ, расходует 110 Мб оперативной памяти, пасьянс QT с открытой игрой Free Cell — 90 Мб, калькулятор Speed Crunch — 30 Мб. Для большинства современных компьютеров дополнительный расход памяти на погружение приложения в изолированную графическую среду совершенно незаметен. Однако на устаревших аппаратных платформах, а также при запуске в изолированной среде большого количества графических приложений производительность ОССН может снижаться.

В ОССН версии 1.3 или более ранних изолированная среда выполнения графических приложений не поддерживалась. Мандатное управление доступом к сущностям графического интерфейса было реализовано путем внесения в программный код Х-сервера дополнительных проверок, не позволяющих процессам реализовывать запрещённые информационные потоки с использованием графического интерфейса. Начиная с версии 1.4, необходимость в этих проверках в значительной степени утрачена, однако программный код, реализующий мандатное управление доступом, не удалялся из графической подсистемы. В современных версиях ОССН он играет роль дополнительного эшелона защиты.

3 . Особенности аутентификации

Подобно другим современным Linux-системам, подсистема аутентификации ОССН построена на основе архитектуры PAM.

PAM — Pluggable Authentication Modules (Подключаемы Модули Безопасности).

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

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

В Astra Linux SE к стандартному набору модулей PAM добавлены четыре дополнительных модуля, реализующие назначение мандатных атрибутов, уровня целостности и специфических привилегий ОССН первому процессу в сеансе работы пользователя с ОССН. Если клиентская программа РАМ в ходе аутентификации не обращается к перечисленным модулям, сеанс пользователя, аутентифицированного данной программой, получает низкий уровень целостности и нулевые мандатные атрибуты, не дающие никаких прав доступа к конфиденциальным данным.

В ОССН не предъявляется никаких специальных требований к РАМ-модулям. Любой такой модуль, разработанный для любой Linux-системы, должен корректно функционировать в ОССН. В файл /etc/pamd/common-password по умолчанию включён РАМ- модуль pam-cracklib.so, запрещающий назначать пользователям простые пароли, нестойкие к подбору.

Администрирование подсистемы аутентификации осуществляется с использованием графической утилиты fly-admin-smc («Управление политикой безопасности»). Пароль и основные параметры аутентификации для пользователя задаются при регистрации учётной записи на вкладках «Общие», «Блокировка», «Срок действия» элемента меню «Пользователи»/ <имя пользователя>» (рис. 3.17).

Рис. 3.17. Основные настройки учётной записи пользователя

Основные элементы вкладок имеют следующее назначение.

• Пароль: изменить — позволяет администратору ОССН принудительно назначить пользователю новый пароль. Это самый простой способ устранить проблему, если пользователь забыл свой пароль.
• Срок действия учётной записи пользователя — если заполнено, по достижении указанной даты учётная запись данного пользователя будет автоматически заблокирована. Пользователь, учётная запись которого заблокирована, не может входить в систему до тех пор, пока администратор ОССН не снимет блокировку.

Чаще всего все вышеперечисленные свойства учётной записи пользователя однократно задаются при её регистрации и более не изменяются, однако при необходимости администратор ОССН может в любой момент изменить любое её свойство.

Рис. 3.18. Вкладка «Параметры пароля» графической утилиты fly-admin-smc

Политики паролей задаются в разделе «Политики паролей» графической утилиты fly-admin-smc. Политика паролей разделена на три части, размещённые в окне графической утилиты fly-admin-smc на трёх вкладках.

Основные элементы вкладок имеют следующее назначение.

• Число дней неактивности после устаревания пароля до блокировки учётной записи пользователя — описывает поведение ОССН в случае, если устаревание пароля произошло в период долгой неактивности пользователя, когда пользователь не входил в систему много дней подряд, обычно такие ситуации связаны с отпуском, командировкой или болезнью. Если значение данного поля равно N, ОССН разрешает единственный вход по устаревшему паролю в течение N дней после устаревания, затем учётная запись блокируется. Специальное значение — 1 (установлено по умолчанию) требует блокировать учётную запись пользователя немедленно после устаревания пароля.
• Минимальное количество дней между сменой пароля — описывает минимальный интервал времени между двумя последовательными сменами пароля. Специальное значение 0 (задано по умолчанию) разрешает менять пароль немедленно после предыдущего изменения.
• Максимальное число дней работоспособности пароля — описывает максимальный срок действия пароля, по истечении которого пароль устаревает. По умолчанию задан максимально допустимый для ввода в окне срок 99999 дней, что составляет немногим менее 274 лет и фактически отключает данную политику.
• Число дней выдачи предупреждения до смены пароля — описывает поведение ОССН, когда пароль учётной записи пользователя вот-вот устареет. Если значение данного поля равно ЛГ, то за N дней до устаревания пароля при каждом успешном входе в систему пользователю выдаётся предупреждение, что его пароль скоро устареет.
• Минимальная длина пароля — устанавливает минимально допустимую длину пароля. При попытке назначить новым паролем более короткую строку пользователь получит отказ. Поскольку пароли учётных записей пользователей хранятся в ОССН в виде хеш-функций, не допускающих обратное преобразование за полиномиальное время, пароль может быть проверен на соответствие данному параметру только в момент установки или проверки. Поэтому изменение данного параметра политики паролей не влияет на уже установленные пароли, они продолжают действовать, даже если они противоречат новой политике паролей.
• Максимальное количество символов в нижнем регистре, Максимальное количество символов в верхнем регистре, Максимальное количество цифр, Максимальное количество других знаков — позволяют администратору ОССН требовать от пользователей, чтобы те использовали трудноподбираемые пароли, составленные из символов, принадлежащих к различным классам. Данные параметры политики позволяет запрещать применение длинных, но нестойких паролей, наподобие «аааааааааааааааа» или «1234567890123456». Специальное значение —1 означает, что данный элемент политики паролей отключён.

Вторая часть политики паролей администрируется с помощью второй вкладки — «Управление блокировками» (рис. 3.19).

Рис. 3.19. Раздел «Управление блокировками» политики паролей

Основные элементы второй вкладки имеют следующее назначение.

• Использовать индивидуальные настройки — разрешает или запрещает вводить для отдельных учётных записей пользователей индивидуальные параметры управления блокировками.
• Не использовать счетчик для пользователя с uid = 0 — запрещает или разрешает применять автоматическое блокирование для учётной записи пользователя с UID = 0 (обычно это суперпользователь root). Если автоматическое блокирование запрещено для данной учётной записи пользователя, это фактически разрешает нарушителю подбирать её пароль сколько угодно долго. Если же блокирование разрешено, это позволяет нарушителю временно запрещать суперпользователю вход в систему, имитируя попытки подбора пароля суперпользователя, что в отдельных конфигурациях ОССН может нарушить её работоспособность. По умолчанию автоматическое блокирование учётной записи пользователя с UID = 0 разрешено.
• Число неуспешных попыток — максимально допустимое количество неуспешных попыток входа в систему, после превышения которого учётная запись пользователя автоматически блокируется.

• Период блокировки — длительность в секундах периода времени, на который блокируется учётная запись пользователя, превысившего максимально допустимое количество неуспешных попыток входа в систему.
• Период разблокировки — длительность в секундах периода времени, по истечении которого отменяется блокировка, наложенная на учётную запись пользователя, превысившего максимально допустимое количество неуспешных попыток входа в систему. Помимо глобальной политики паролей, в системе могут существовать другие политики. Для создания новой политики паролей следует воспользоваться контекстным меню раздела «Политики паролей» или любого его подраздела. Если политика паролей не является глобальной, то в соответствующем окне имеется возможность записать текущее состояние политики паролей в глобальную политику.

Параметры пароля, действующие в отношении конкретной учётной записи пользователя, задаются на вкладке «Дополнительные» элемента «Пользователи и группы / Пользователи / Локальные пользователи / <имя пользователя>» (рис. 3.20).

Рис. 3.20. Дополнительные настройки учётной записи пользователя

Основные элементы вкладки имеют следующее назначение:

• Gecos — значение элемента GECOS учётной записи пользователя. Данный элемент используется некоторым устаревшим ПО для хранения дополнительной информации о учётной записи пользователя (полное имя, должность, номер комнаты, номер телефона и т. д.), не имеет отношения к обеспечению безопасности. По умолчанию имеет вид «%username%„,».
• Домашняя директория — каталог, в котором будут размещаться документы и настройки данной учётной записи пользователя. По умолчанию имя домашнего каталога имеет вид «/home/ %username%».
• Создать — если опция включена (по умолчанию), домашний каталог учётной записи пользователя автоматически создаётся при её регистрации.
• Командная оболочка — командный интерпретатор, запускаемый в качестве командной оболочки (shell) в текстовых терминалах, с которыми работает данный пользователь. По умолчанию используется командный интерпретатор / bin/bash.
• Профиль политики — позволяет установить параметры политики пароля, заданной для учётной записи пользователя, в соответствии с выбранной общесистемной политикой. По умолчанию при регистрации новой учётной записи пользователя ей назначаются параметры политики, соответствующие глобальной политике паролей, после чего для данного поля устанавливается специальное значение «(Текущие параметры пароля)», позволяющее произвольным образом менять параметры, не привязываясь ни к какой конкретной политике.
• Число дней неактивности после устаревания пароля до блокировки учётной записи, Минимальное количество дней между сменой пароля, Максимальное число дней работоспособности пароля, Число дней выдачи предупреждения до смены пароля — аналогичны одноимённым параметрам глобальной политики паролей. Заметим, что не все параметры глобальной политики паролей допускают переопределение для конкретных учётных записей пользователей.
• Мандатные атрибуты — мандатные атрибуты учётной записи пользователя, их назначение было описано ранее.

Наряду с графической утилитой fly-admin-smc, для администрирования подсистемы аутентификации ОССН могут применяться, например, следующие команды, аналогичные соответствующим командам Debian GNU/Linux:

• addgroup, groupadd — создают группу пользователей;
• adduser, user add — создают учётную запись пользователя;
• chfn — изменяет элемент GECOS учётной записи пользователя;
• chpasswd — позволяет последовательно поменять пароли нескольким учётным записям пользователя, применяется в скриптах, реализующих регистрацию учётных записей пользователей в пакетном режиме;
• chsh — изменяет командный интерпретатор (shell), выбранный для учётной записи пользователя;
• delgroup, groupdel — удаляют группу пользователей;
• deluser, userdel — удаляют учётную запись пользователя;
• gpasswd — позволяет управлять членством учётных записей пользователей в группах;
• groupmod — позволяет переименовать группу пользователей или изменить её внутренний числовой идентификатор;
• grpck — проверяет корректность формата и содержания файлов, хранящих информацию о группах пользователей;
• newgrp — добавляет учётную запись пользователя в группу;
• newusers — позволяет одновременно создать или обновить несколько учётных записей пользователей в пакетном режиме;
• passwd — меняет пароль учётной записи пользователя;
• pwck — проверяет корректность формата и содержания файлов, хранящих информацию о учётных записях пользователей;
• usermod — изменяет свойства учётной записи пользователя.

4 . Особенности аудита

Помимо стандартного для Debian GNU/Linux демона rsyslogd, в ОССН также имеется собственная система аудита, реализуемая подсистемой безопасности PARSEC, позволяющая более эффективно управлять регистрацией событий, непосредственно связанных с безопасностью ОССН. Архитектура аудита PARSEC показана на рис. 3.21.

Зарегистрированные события записывают в файлы kernel.mlog и user.mlog, по умолчанию размещаемые в каталоге /var/log/ parsec. Каждая запись файла соответствует одному зарегистрированному событию и содержит следующие данные:

• имя учётной записи пользователя;
• источник события;
• время регистрации события;
• имя процесса;
• статус выполнения системного вызова, приведшего к регистрации события: успех ([s]) или отказ ([/]);
• имя, параметры и возвращаемое значение системного вызова, приведшего к регистрации события.

Рис. 3.21. Архитектура аудита PARSEC

Рис. 3.22. Утилита просмотра журналов аудита

Для просмотра зарегистрированных событий аудита используется графическая утилита fly-admin-viewaudit, интерфейс которой показан на рис. 3.22.

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

Управление фильтрацией событий аудита осуществляется по команде меню «Фильтр / Изменить» с использованием интерфейса, показанного на рис. 3.23.

Рис. 3.23. Управление фильтрацией событий аудита

Основные элементы интерфейса имеют следующее назначение:

• Заголовок интерфейса содержит имя редактируемого фильтра.
• Время — позволяет задать интервал времени, к которому должны принадлежать отображаемые события аудита. Можно указать в явном виде начальный и конечный моменты, воспользоваться одним из предопределённых значений, либо отключить фильтрацию событий аудита по времени.
• Статус — позволяет фильтровать отображаемые события аудита по статусу выполнения системного вызова. Если в фильтре выбран только один статус, в окно утилиты выводятся только события аудита с этим статусом, если выбраны или не выбраны оба статуса, фильтрация событий аудита по статусу отключена.
• Источник — позволяет фильтровать отображаемые события аудита по источнику. Если в фильтре не выбран ни один источник, фильтрация по источнику отключена, и в окно утилиты выводятся события аудита с любым источником, так же как когда выбраны все три источника.
• Файлы — позволяет ограничить отображаемые события аудита определённой областью файловой системы ОССН.
• Дополнительные параметры — позволяет фильтровать события аудита, содержащие заданные подстроки в соответствующих полях строки, описывающей событие.
• События — позволяет фильтровать отображаемые события аудита по типу системного вызова, с которым оно связано.

Политикой аудита удобнее всего управлять с помощью графической утилиты fly-admin-smc («Управление политикой безопасности»). Аналогично политикам паролей в ОССН может одновременно действовать несколько политик аудита.

Каждая политика аудита может быть применена к конкретной учётной записи пользователя или к группе пользователей, кроме того, существует общесистемная политика, действующая по умолчанию. Создание и редактирование политик аудита осуществляется разделе «Аудит» (рис. 3.24).

Рис. 3.24. Настройка политики аудита

Политика аудита кодируется двумя битовыми масками, в которых каждый бит соответствует категории событий, регистрируемых подсистемой аудита. Одна маска перечисляет успешные события (т. е. события, соответствующие успешным попыткам доступа субъектов к сущностям), другая — неуспешные события. Каждая категория событий аудита соответствует одному или нескольким системным вызовам, при реализации которых, если соответствующая категория включена, то генерируется событие аудита. В ОССН версии 1.4 реализуются следующие категории событий аудита:

• open — открытие файловой сущности (файла или каталога);
• create — создание файловой сущности;
• ехес — выполнение программного файла;
• delete — удаление файловой сущности;
• chmod — изменение дискреционных атрибутов файловой сущности (типичного для ОС семейства Linux вектора прав доступа);
• chown — изменение владельца файловой сущности;
• mount — монтирование или размонтирование внешнего носителя данных;
• module — загрузка или выгрузка модуля расширения ядра ОССН;
• uid — смена идентификатора учётной записи пользователя для процесса;
• gid — смена идентификатора группы для процесса;
• audit — изменение политики аудита;
• a cl — изменение дискреционных атрибутов файловой сущности;
• mac — изменение мандатных атрибутов файловой сущности;
• cap — изменение привилегий учётной записи пользователя или группы;
• chroot — смена корня файловой системы ОССН для процесса;
• rename — переименование файловой сущности;
• net — некоторые сетевые операции.

Каждой учётной записи пользователя и группе ОССН может быть сопоставлена своя политика аудита. Для создания новой политики аудита используются контекстные меню разделов «Аудит/ Группы пользователей» или «Аудит/Пользователи» соответственно.