Подсистема контроля регистрирует события в системе, связанные с секретностью, записывая их в контрольный журнал, который затем можно просмотреть. В контрольных журналах, выдаваемых подсистемой, можно фиксировать проникновение в систему и неправильное использование ресурсов. Подсистема контроля спроектирована в соответствии с задачами контроля, определяемыми Национальным центром защиты данных компьютеров США.
Контроль позволяет просматривать собранные данные для изучения образцов доступа к объектам и наблюдения за действиями отдельных пользователей и их процессов. Попытки нарушения защиты и механизмов авторизации контролируются. Подсистема контроля дает высокую степень гарантии обнаружения попыток обойти механизмы обеспечения безопасности. Поскольку события, связанные с секретностью, контролируются и поддаются учету вплоть до выявления конкретного пользователя, подсистема контроля служит сдерживающим средством для пользователей, пытающихся неправильно воспользоваться системой.
Подсистема контроля использует системные вызовы и утилиты для классификации действий пользователей, подразделяя их на типы событий. Это можно использовать для выборочной генерации и редукции контроля. Один из этих типов событий, Отказ дискреционного доступа (DAC), регистрирует попытки такого использования объектов, которое не допускается разрешениями для этого объекта. Например, если пользовательский процесс пытается писать в файл "только для чтения", регистрируется событие Отказа DAC, показывающее, что процесс пытался произвести запись в файл, на что у него не было права. Если просмотреть контрольный журнал, то легко будет заметить повторяющиеся попытки доступа к файлам, на которые не выданы разрешения.
Для эффективности данных контроля существенна возможность учета пользователей, выполняющих действия, подлежащие контролю. Когда пользователи пытаются войти в систему, они должны пройти процесс идентификации и аутентификации, прежде чем им будет предоставлен доступ в систему. Механизм секретности снабжает каждый процесс, создаваемый пользователем, постоянным индикатором идентичности - регистрационным идентификатором пользователя (LUID). Этот идентификатор сохраняется невзирая на переходы от одного пользовательского бюджета к другому с помощью таких команд, как su(C). Каждая контрольная запись, генерируемая подсистемой, содержит LUID наряду с эффективным и реальным идентификаторами пользователя и группы для процесса. В итоге оказывается возможным строгий учет действий пользователей.
Подсистема контроля управляется Администратором контроля. Будучи Администратором контроля, вы обладаете полным контролем над событиями, выбранными для генерации контрольных записей, над значениями параметров подсистемы контроля и над последующей редукцией и анализом данных контроля.
Подсистема контроля состоит из четырех главных компонентов:
Существует несколько надежных системных утилит, которые, хотя на самом деле и не являются собственно частью подсистемы контроля, отвечают за занесение контрольных записей в контроль- ный журнал (например, login(M)).
Механизм контроля ядра является центральным в подсистеме контроля. Этот механизм генерирует контрольные записи, исходя из активности пользовательских процессов, с помощью системных вызовов ядра. Каждый системный вызов ядра содержит строку в таблице подсистемы, где указано, связан ли этот вызов с вопросами секретности, и если это так, то какому типу события он соответствует. Кроме того, используется таблица кодов ошибок, позволяющая классифицировать системные вызовы на конкретные события, связанные с секретностью. Механизм контроля ядра выдает внутренний вызов в драйвер устройства для занесения записи в контрольный журнал.
Например, системный вызов open(S) классифицируется как событие Сделать объект доступным. Если пользователь blf выполняет open(S) для /unix и делает это успешно, генерируется контрольная запись об этом событии. Однако если системный вызов заканчивается неудачно из-за того, что blf запросил в open(S) доступ по записи, не имея разрешения на запись в этот файл, это действие классифицируется как событие Отказ дискреционного доступа для blf и объекта /unix. Следовательно, системный вызов можно отобразить в несколько типов событий, в зависимости от объекта, к которому осуществляется доступ, и/или результата вызова. Поэтому возникает возможность выборочного контроля системных вызовов, в зависимости от типов событий, которые вы сделаете доступными.
Некоторые системные вызовы не относятся к секретности. Например, getpid(S) получает идентификатор процесса и не определяет событие, связанное с секретностью. Таким образом, этот системный вызов не подлежит контролю.
Драйвер устройства контроля выполняет следующие функции: прием контрольных записей от механизма контроля ядра и от надеж- ных утилит; создание и запись промежуточных файлов контрольного журнала; предоставление данных контрольного журнала демону конт- роля для уплотнения; обеспечение выборочной генерации контроль- ных записей на основе типов событий, идентификаторов пользовате- лей и идентификаторов групп.
Драйвер устройства обеспечивает интерфейсы open(S), close(S), read(S), write(S) и ioctl(S), как и прочие символьные устройства. Однако устройство контроля может быть открыто только процессами, обладающими авторизациями ядра configaudit и/или writeaudit. Это ограничивает доступ к устройству контроля, раз- решая его только для надежных утилит, таких как интерфейсы демо- на контроля и Администратора контроля. В устройство контроля мо- гут писать несколько процессов одновременно. Это устройство про- изводит объединение записей в контрольный журнал. Читать с устройства может только один процесс - демон контроля.
Драйвер устройства контроля ведет контрольный журнал в виде набора файлов сбора данных контроля. Каждый раз, когда вы вклю- чаете контроль, начинается новая сессия контроля. При ее запуске подсистема создает файл сбора данных, в который заносятся конт- рольные записи. Когда файл сбора данных достигает определенного размера, установленного администратором, подсистема создает но- вый файл сбора данных и начинает писать в него. Поэтому конт- рольный журнал можно рассматривать как постоянно увеличивающийся последовательный файл, даже если используется несколько файлов сбора данных. Именно в таком виде контрольный журнал рассматри- вается демоном контроля, потому что он читает с устройства и по- лучает записи из контрольного журнала. При достижении конца фай- ла сбора данных подсистема выполняет соответствующее переключе- ние на новый файл сбора данных. Все это прозрачно для демона.
Демон контроля auditd(ADM) - это надежная утилита, выполняющаяся как фоновый демон-процесс при включении контроля. Этот демон - единственный, кто читает с устройства контроля, которое в свою очередь представляет демону блоки записей из файлов сбора данных контроля. Демону безразлично, что контрольный журнал расслаивается на множество файлов сбора данных. Драйвер устройства контроля удовлетворяет запросы на чтение, поступающие от демона, и обрабатывает переключение и удаление файлов сбора данных по мере надобности.
Главное предназначение демона состоит в предоставлении механизма уплотнения данных и регистрации для сессии контроля. Демон также выполняет функцию поддержки защищенных подсистем, позволяя им писать в подсистему контрольные записи. В зависимости от выбранного вами критерия формирования контрольных записей, в системе может быть сгенерировано огромное количество данных контроля. В типичном случае однопользовательской системы генерация 200 килобайтов данных контроля за час не будет выглядеть необычно. Поэтому демон предоставляет механизм уплотнения для сжатия данных контроля в упакованный формат записи, которая сохраняется в файле уплотнения контроля.
Второй функцией демона является обеспечение журнального файла, описывающего текущую сессию контроля. Журнальный файл содержит информацию о количестве контрольных записей, доступных в уплотненных файлах вывода в сессии; время запуска и останова сессии; а также другие индикаторы состояния сессии контроля. Как только драйвер устройства контроля переключает файлы сбора данных при достижении ими размеров, установленных администратором, демон может создать несколько уплотненных файлов, чтобы не допустить увеличения одного файла до размеров, недоступных управлению. Вы также это контролируете. Кроме того, уплотненные файлы, записанные демоном, можно разместить в любом каталоге, определенном администратором. По этим причинам ведется журнальный файл - чтобы иметь журнал с уплотненными файлами, которые можно использовать для последующей редукции данных.
Третья функция демона контроля - выполнять роль программы интерфейса с драйвером устройства контроля для занесения контрольных записей из защищенных подсистем, не имеющих авторизации writeaudit. Так как эти подсистемы не могут осуществлять доступ непосредственно к драйверу устройства контроля, но могут образовать интерфейс с демоном с соблюдением секретности, то демон выполняет занесение контрольной записи прикладной программы в подсистему.
sysadmsh предоставляет простые возможности для установки и сопровождения подсистемы контроля. Это позволяет администратору выполнять установку и инициализацию, модифицировать параметры подсистемы, сопровождать подсистему (резервное дублирование, восстановление и т.д.) и выполнять редукцию как общих, так и выборочных данных контроля.
sysadmsh также включает в себя утилиту редукции/анализа данных, которая облегчает исследование контрольных журналов предыдущих сессий контроля или текущей сессии контроля. Используя журнальный файл, созданный демоном контроля, утилита редукции может идентифицировать все уплотненные файлы, нужные для редукции сессии контроля. Так как уплотненные файлы имеют сжатый формат, программа редукции содержит подпрограммы, необходимые для развертывания файлов.
Для обеспечения эффективного анализа данных контроля утилита редукции позволяет задавать для выборочной редукции данных определенные типы событий, идентификаторы пользователей, идентификаторы групп и имена объектов. Более того, вы можете задать интервал времени, в течение которого должен производиться поиск записей, удовлетворяющих выбранному критерию. Если какая-либо запись не попадает в этот интервал, она отбрасывается в данной редукции.
Например, вы можете выполнять редукцию данных, выбирая событие Отказа DAC для пользователя с идентификатором blf, ведущего поиск объекта /unix. Будут распечатаны только те записи, которые отражают попытки доступа blf к /unix, отвергнутые ввиду отсутствия нужных разрешений. Это образует мощный механизм для идентификации событий секретности, представляющих актуальный интерес, без анализа всего контрольного журнала.