Подсистема контроля позволяет системному администратору сохранять данные, относящиеся к защите системы. В дальнейшем, проанализировав их, он сможет обнаружить реальные и потенциальные нарушения стратегии защиты системы. Подсистема контроля выполняет следующие три функции:
Системный администратор может настраивать каждую из этих функций.
В обнаружении событий принимает участие как ядро Защищенной компьютерной базы (TCB) (режим супервизора), так и защищенные программы (пользовательский режим). Возможно обнаружение любого события в системе, имеющего отношение к защите. К таковым относится любое изменение состояния защиты, любая попытка или действительное нарушение доступа к системе, а также отчетности в системе защиты. Программы и модули ядра, обнаруживающие отслеживаемые события, должны сообщать о таких событиях системной программе ведения протокола контроля, представляющей собой часть ядра. Обратиться к этой программе можно либо с помощью подпрограммы (в пользовательском режиме), либо из процедуры ядра (в режиме супервизора). Передаваемая информация включает название отслеживаемого события, сведения о его успешном или неудачном завершении, а также другую дополнительную информацию, имеющую отношение к системе защиты.
Настройка программы отслеживания событий заключается в ее включении-выключении и выборе между двумя режимами: глобального отслеживания (на системном уровне) и локального отслеживания (на уровне процесса). Для включения и выключения глобального отслеживания контролируемых событий предназначена команда audit. Локальный контроль за событиями заключается в отслеживании групп контролируемых событий, принадлежащих конкретным пользователям (классов контролируемых событий).
При сборе данных выполняется регистрация выбранных отслеживаемых событий. За эту функцию отвечает программа ведения протокола ядра, обеспечивающая как работу с подпрограммой SVC, так и интерфейс вызова внутренних процедур ядра, регистрирующих события.
Программа ведения протокола
формирует полную запись протокола контроля, включающую заголовок с
информацией, общей для всех событий (название события, имя пользователя, время
и состояние события), а также блок информации с данными, характерными только
для данного типа событий. Программа ведения протокола добавляет каждую
последующую запись к контрольному следу в ядре. Запись контрольного
следа можно вести в любом из двух режимов (или в обоих режимах):
Можно настроить обе части процесса сбора данных - как запись события, так и обработку контрольного следа в ядре. Вы можете записывать события, относящиеся к конкретному пользователю. Для каждого пользователя определен собственный набор событий контроля, которые и записываются в контрольный след. В системе предусмотрена возможность независимой настройки каждого режима обработки контрольного следа и системный администратор может применить наиболее подходящий для данной среды способ. Кроме того, можно настроить режим лотка таким образом, чтобы в случае сбоя система завершала работу.
Операционная система обеспечивает несколько вариантов обработки контрольного следа в ядре. В режиме лотка перед отправкой в архив контрольный след может быть сжат, обработан с помощью фильтров или отформатирован для вывода. При сжатии применяется метод Хаффмана. Фильтрация выполняется путем выбора отдельных записей контроля (с помощью команды auditselect и операторов, аналогичных операторам SQL) и обеспечивает как выборочный просмотр, так и выборочное сохранение контрольного следа. Форматирование записей контрольного следа применяется для их проверки и просмотра, создания периодических отчетов о состоянии защиты, а также для печати копии контрольного следа. За контрольным следом, созданным в режиме потока, можно следить постоянно, и немедленно обрабатывать полученные данные. Этой функцией управляют независимые программы-демоны, которые могут фильтровать данные обоих режимов, хотя некоторые из них предназначены для какого-либо одного режима.
Контролируемые события, а также степень тщательности контроля определяются набором подлежащих контролю событий. Как уже было сказано ранее, в этот набор должны входить все события, имеющие отношение к защите системы. При создании определения контролируемого события необходимо избежать как излишне подробного описания (которое затруднит для системного администратора понимание полученной информации), так и недостаточного описания (которое приведет к сбору слишком большого объема данных). Описания сходных обнаруженных событий также очень похожи между собой. Мы будем считать, что обнаруженное событие - это отдельный экземпляр контролируемого события; например, определенное событие может быть обнаружено в различных местах. Основной принцип заключается в том, что обнаруженные события со сходными свойствами (в отношении защиты системы) считаются одним и тем же контролируемым событием. Ниже приведена классификация событий:
События, связанные со стратегией защиты
События субъекта
- создание процесса
- удаление процесса
- установка атрибутов защиты: ИД пользователя или группы
- группа процессов, управление терминалом
События объекта
- создание объекта
- удаление объекта
- открытие объекта (включая и процессы в качестве объектов)
- закрытие объекта (включая и процессы в качестве объектов)
- установка атрибутов защиты объекта: владельца, группы и списков ACL
События импорта/экспорта
- импорт или экспорт объекта
События учета
- добавление пользователя, изменение пользовательских атрибутов базы
данных паролей
- добавление группы, изменение атрибутов группы в базе данных групп
- вход пользователя в систему
- выход пользователя из системы
- изменение данных идентификации пользователя
- настройка терминала защищенного пути
- настройка идентификации
- управление контролем: выбор событий и контрольных следов,
включение и выключение, определение пользовательских классов
контроля
Общие события администрирования системы
- использование привилегий
- настройка файловой системы
- определение и настройка устройства
- определение параметров настройки системы
- выполнение IPL или завершение работы системы
- настройка RAS
- настройка прочих системных параметров
Нарушения защиты (возможные)
- случаи отказа в предоставлении прав доступа
- ошибки при определении привилегий
- сбои и системные ошибки, обнаруженные программами
диагностики
- нарушение TCB (или попытка нарушения).
Переменная глобального состояния подсистемы контроля показывает, включена подсистема или нет. Кроме того, у каждого процесса есть локальная переменная состояния, значение которой показывает, следует ли подсистеме контроля записывать данные об этом процессе. Обе переменные показывают, были ли обнаружены какие-либо события модулями и программами Защищенной компьютерной базы (TCB). Если отключить для определенного процесса контроль TCB, то этот процесс сможет выполнять контроль самостоятельно, не влияя при этом на стратегию отчетности системы. Самостоятельный контроль защищенной программы обеспечивает более эффективный сбор данных.
При сборе данных применяется функция обнаружения событий и контрольный след. Все необходимые функции выполняет процедура ядра, с помощью которой компоненты TCB обнаруживают контролируемые события, и интерфейсы настройки, через которые подсистема контроля управляет процедурой занесения событий в протокол.
Занесение отслеживаемых событий в протокол выполняется с помощью одного из интерфейсов: пользовательского режима или режима супервизора. Пользовательский компонент TCB вызывает для этого подпрограмму auditlog или auditwrite, а компонент TCB, работающий в режиме супервизора, использует набор вызовов процедур ядра.
Программа занесения в протокол добавляет контрольный заголовок к информации о каждом событии. В заголовке указано имя пользователя и процесса отслеживаемого события, а также время, когда оно произошло. Обнаружившая событие программа сообщает следующие данные: тип события, код возврата или его состояние. Иногда передается дополнительная информация о событии (контрольный след события). Эта дополнительная информация включает в себя имена объектов (например, имена файлов, доступ к которым был запрещен, или имена терминалов tty, на которых произошел сбой при попытке входа в систему), параметры подпрограмм и прочие данные.
Для определения событий, как правило, используются символьные имена, а не числовые. При отсутствии четкой схемы регистрации событий это позволяет снизить вероятность конфликтов имен. Поскольку подпрограммы также контролируются, а у расширяемых определений ядра нет фиксированных номеров SVC, то записывать события по номерам достаточно проблематично. Это связано с тем, что правила нумерации необходимо пересматривать при каждом расширении или переопределении ядра.
Контрольная запись состоит из общего заголовка и прикрепленного к нему контрольного следа, который содержит информацию, описывающую конкретное событие. Структуры заголовка определены в файле /usr/include/sys/audit.h. Формат контрольного следа зависит от типа события. Форматы для основных событий определены в файле /etc/security/audit/events.
Сбор данных для контрольного заголовка обычно выполняет процедура занесения в протокол, обеспечивающая большую точность, а данные контрольного следа предоставляет программа, обнаружившая событие. Программа занесения в протокол не знакома со структурой и семантикой представления данных контрольного следа. Например, обнаружив ошибку при входе с систему, команда login определяет имя терминала и специальные данные об этом событии, а затем с помощью подпрограммы auditlog записывает эту информацию в контрольный след. Программа создания протокола ядра записывает специальную информацию об объекте (ИД пользователя и процесса, время) в заголовок, который добавляется к прочим данным. Единственное, что записывает сама вызывающая программа - это расположенное в заголовке имя события и поле результата.
Задачей программы ведения протокола является составление полной контрольной записи. Вы должны выбрать, какие события необходимо заносить в протокол.
Существует два типа процедуры
выбора событий: для процессов и для объектов.
Объект, в который будет записываться контрольный след, зависит от режимов занесения в протокол ядра (режим лотка и режим потока). В режиме лотка программе ведения контрольного протокола ядра перед запуском контроля необходимо передать по крайней мере один дескриптор файла, в который будут добавляться записи протокола.
В режиме лотка контрольные данные записываются в сменяющиеся файлы. В момент запуска процесса контроля в ядро передаются два дескриптора файлов и рекомендуемое значение максимального размера файла-приемника. Вызывающий процесс приостанавливается, и начинается запись контрольных данных в первый файл. Когда размер первого файла-приемника достигает максимального значения, процесс переключается на второй файл (если он указан верно), а вызывающий процесс вновь активируется. Процесс продолжает запись во второй файл до тех пор, пока он не будет вызван снова с указанием следующего дескриптора файла. Если в этот момент второй файл полон, то процесс переключится обратно на первый файл-приемник, и вызывающий процесс немедленно возобновится. В противном случае, процесс приостановится, и ядро продолжит записывать данные во второй файл до тех пор, пока он не заполнится. Таким образом обработка продолжается вплоть до ее выключения.
Режим потока устроен несколько проще, чем режим лотка. Ядро добавляет записи в замкнутый буфер. Когда буфер заполняется, ядро просто начинает снова записывать данные в его начало. Процессы ядра считывают информацию с помощью псевдоустройства /dev/audit. В момент открытия процессом устройства, для процесса создается новый канал. События, считываемые на данном канале, можно определить в виде списка классов контроля.
Основное назначение потокового режима заключается в возможности периодического чтения контрольного следа, позволяющего обеспечить контроль защиты в реальном времени. Еще одна область применения этого режима - немедленная печать данных контрольного следа, без необходимости вмешательства и нарушения контрольного следа (это может произойти, если след хранится на каком-либо носителе).