Access Control Decision Facility (ADF) содержит мощную систему регистрации
событий. Имеется возможность указать события, которые будут зарегистрированы
в зависимости от типа запроса, пользователя, выполняемого и целевого
объекта (файла, FIFO, каталога или устройства). Некоторые из этих
особенностей должны быть задействованы в конфигурации ядра.
Регистрируемыми событиями являются запросы, идентификаторы процессов,
названия программ, идентификаторы реальных пользователей или псевдонимов,
типы объектов, идентификаторы объектов, типы атрибутов, значения атрибутов,
решения ADF и названия модулей принявших эти решения.
Для каждого регистрируемого ключа уровень регистрации может быть установлен
индивидуально, в зависимости от типа запроса.
Имеются три уровня регистрации для запросов: none, denied requests
only и full. 'Denied' - это значение по умолчанию для всех запросов
. Оно позволит вам видеть все запрещенные запросы в журнале, не смотря
на то, что протоколирование никогда не было настроено.
Для объектов (только файлы, FIFO, каталоги и устройства), имеются
четыре уровня регистрации: none, denied requests only, full и request
based (s.a.). Для этого типа объектов значением по умолчанию является
- request based (смотри ниже).
Для пользователей и исполняемых файлов, которые имеют только два уровня:
none и full. По умолчанию конечно none.
Протоколирование по запросу устанавливается средствами командной строки
switch_adf_log, текущие значения могут быть просмотрены в /proc/rsbac-info/adf_loglevel.
Настройки индивидуального протоколирования реализованы как атрибуты
и могут быть установлены при помощи обычных средств.
Как и любой доступ, доступ к настройкам регистрации событий является
контролируемым, каждая модель может реализовать свою схему контроля
доступа для собственной защиты.
Всякий раз, когда запрос пробежал все модули, диспетчер решения проходит
следующий алгоритм, чтобы решить, должен ли быть зарегистрирован запрос.
Обратите пожалуйста внимание, что протоколирование имеет место, если
по крайней мере на одном из этих шагов будет принято решение, что
протоколирование необходимо. Так что решение 'протокол' прерывает
алгоритм.
1. Если включена индивидуальная регистрация действий пользователя
и пользовательским уровнем регистрации для запроса является
none: переходим к шагу 2
full: протоколирование
2. Если задействовано индивидуальное протоколирование программы и
уровнем регистрации программы для запроса является
none: переходим к шагу 3
full: протоколирование
3. Если задействовано индивидуальное протоколирование объекта, объект
является файлом, FIFO, каталогом или устройством и уровнем регистрации
объекта для запроса является
none: нет протоколирования
denied: протоколирование ведется в том случае, если результатом является
NOT_GRANTED, в противном случае не регистрируется
full: протоколирование
request based: переходим к шагу 4
4. Если уровнем регистрации для запроса является
none: нет протоколирования
denied: протоколирование ведется в том случае, если результатом является
NOT_GRANTED, в противном случае не регистрируется
full: протоколирование
Алгоритм также используется для определения, будет ли зарегистрирован
вызов rsbac_adf_set_attr(). Эта функция вызывается из большинства
точек перехвата для указания модулям принятия решений, что функции
перехвата были успешно выполнены и они должны поправить значения их
атрибутов. Также, это единственный способ сообщить модулям принятия
решений о недавно созданных объектах.