Страница:
контроля. Этот механизм генерирует контрольные записи, исходя из
активности пользовательских процессов, с помощью системных вызо-
вов ядра. Каждый системный вызов ядра содержит строку в таблице
подсистемы, где указано, связан ли этот вызов с вопросами сек-
ретности, и если это так, то какому типу события он соответству-
ет. Кроме того, используется таблица кодов ошибок, позволяющая
классифицировать системные вызовы на конкретные события, связан-
ные с секретностью. Механизм контроля ядра выдает внутренний вы-
зов в драйвер устройства для занесения записи в контрольный жур-
нал.
Например, системный вызов open(S) классифицируется как со-
бытие Сделать объект доступным. Если пользователь blf выполняет
open(S) для /unix и делает это успешно, генерируется контрольная
запись об этом событии. Однако если системный вызов заканчивает-
ся неудачно из-за того, что blf запросил в open(S) доступ по за-
писи, не имея разрешения на запись в этот файл, это действие
классифицируется как событие Отказ дискреционного доступа для
blf и объекта /unix. Следовательно, системный вызов можно отоб-
разить в несколько типов событий, в зависимости от объекта, к
которому осуществляется доступ, и/или результата вызова. Поэтому
возникает возможность выборочного контроля системных вызовов, в
зависимости от типов событий, которые вы сделаете доступными.
Некоторые системные вызовы не относятся к секретности. Нап-
ример, getpid(S) получает идентификатор процесса и не определяет
событие, связанное с секретностью. Таким образом, этот системный
вызов не подлежит контролю.
Драйвер устройства контроля
Драйвер устройства контроля выполняет следующие функции:
прием контрольных записей от механизма контроля ядра и от надеж-
ных утилит; создание и запись промежуточных файлов контрольного
журнала; предоставление данных контрольного журнала демону конт-
роля для уплотнения; обеспечение выборочной генерации контроль-
ных записей на основе типов событий, идентификаторов пользовате-
лей и идентификаторов групп.
.
- 5-16 -
Драйвер устройства обеспечивает интерфейсы open(S),
close(S), read(S), write(S) и ioctl(S), как и прочие символьные
устройства. Однако устройство контроля может быть открыто только
процессами, обладающими авторизациями ядра configaudit и/или
writeaudit. Это ограничивает доступ к устройству контроля, раз-
решая его только для надежных утилит, таких как интерфейсы демо-
на контроля и Администратора контроля. В устройство контроля мо-
гут писать несколько процессов одновременно. Это устройство про-
изводит объединение записей в контрольный журнал. Читать с
устройства может только один процесс - демон контроля.
Драйвер устройства контроля ведет контрольный журнал в виде
набора файлов сбора данных контроля. Каждый раз, когда вы вклю-
чаете контроль, начинается новая сессия контроля. При ее запуске
подсистема создает файл сбора данных, в который заносятся конт-
рольные записи. Когда файл сбора данных достигает определенного
размера, установленного администратором, подсистема создает но-
вый файл сбора данных и начинает писать в него. Поэтому конт-
рольный журнал можно рассматривать как постоянно увеличивающийся
последовательный файл, даже если используется несколько файлов
сбора данных. Именно в таком виде контрольный журнал рассматри-
вается демоном контроля, потому что он читает с устройства и по-
лучает записи из контрольного журнала. При достижении конца фай-
ла сбора данных подсистема выполняет соответствующее переключе-
ние на новый файл сбора данных. Все это прозрачно для демона.
Демон контроля
Демон контроля auditd(ADM) - это надежная утилита, выполня-
ющаяся как фоновый демон-процесс при включении контроля. Этот
демон - единственный, кто читает с устройства контроля, которое
в свою очередь представляет демону блоки записей из файлов сбора
данных контроля. Демону безразлично, что контрольный журнал
расслаивается на множество файлов сбора данных. Драйвер устройс-
тва контроля удовлетворяет запросы на чтение, поступающие от де-
мона, и обрабатывает переключение и удаление файлов сбора данных
по мере надобности.
Главное предназначение демона состоит в предоставлении ме-
ханизма уплотнения данных и регистрации для сессии контроля. Де-
мон также выполняет функцию поддержки защищенных подсистем, поз-
воляя им писать в подсистему контрольные записи. В зависимости
от выбранного вами критерия формирования контрольных записей, в
системе может быть сгенерировано огромное количество данных
контроля. В типичном случае однопользовательской системы генера-
ция 200 килобайтов данных контроля за час не будет выглядеть не-
обычно. Поэтому демон предоставляет механизм уплотнения для сжа-
тия данных контроля в упакованный формат записи, которая сохра-
няется в файле уплотнения контроля.
Второй функцией демона является обеспечение журнального
файла, описывающего текущую сессию контроля. Журнальный файл со-
держит информацию о количестве контрольных записей, доступных в
уплотненных файлах вывода в сессии; время запуска и останова
сессии; а также другие индикаторы состояния сессии контроля. Как
только драйвер устройства контроля переключает файлы сбора дан-
.
- 5-17 -
ных при достижении ими размеров, установленных администратором,
демон может создать несколько уплотненных файлов, чтобы не до-
пустить увеличения одного файла до размеров, недоступных управ-
лению. Вы также это контролируете. Кроме того, уплотненные фай-
лы, записанные демоном, можно разместить в любом каталоге, опре-
деленном администратором. По этим причинам ведется журнальный
файл - чтобы иметь журнал с уплотненными файлами, которые можно
использовать для последующей редукции данных.
Третья функция демона контроля - выполнять роль программы
интерфейса с драйвером устройства контроля для занесения конт-
рольных записей из защищенных подсистем, не имеющих авторизации
writeaudit. Так как эти подсистемы не могут осуществлять доступ
непосредственно к драйверу устройства контроля, но могут образо-
вать интерфейс с демоном с соблюдением секретности, то демон вы-
полняет занесение контрольной записи прикладной программы в под-
систему.
Доступ к контролю через sysadmsh
sysadmsh предоставляет простые возможности для установки и
сопровождения подсистемы контроля. Это позволяет администратору
выполнять установку и инициализацию, модифицировать параметры
подсистемы, сопровождать подсистему (резервное дублирование,
восстановление и т.д.) и выполнять редукцию как общих, так и вы-
борочных данных контроля.
Средство редукции/анализа данных
sysadmsh также включает в себя утилиту редукции/анализа
данных, которая облегчает исследование контрольных журналов пре-
дыдущих сессий контроля или текущей сессии контроля. Используя
журнальный файл, созданный демоном контроля, утилита редукции
может идентифицировать все уплотненные файлы, нужные для редук-
ции сессии контроля. Так как уплотненные файлы имеют сжатый фор-
мат, программа редукции содержит подпрограммы, необходимые для
развертывания файлов.
Для обеспечения эффективного анализа данных контроля утили-
та редукции позволяет задавать для выборочной редукции данных
определенные типы событий, идентификаторы пользователей, иденти-
фикаторы групп и имена объектов. Более того, вы можете задать
интервал времени, в течение которого должен производиться поиск
записей, удовлетворяющих выбранному критерию. Если какая-либо
запись не попадает в этот интервал, она отбрасывается в данной
редукции.
Например, вы можете выполнять редукцию данных, выбирая со-
бытие Отказа DAC для пользователя с идентификатором blf, ведуще-
го поиск объекта /unix. Будут распечатаны только те записи, ко-
торые отражают попытки доступа blf к /unix, отвергнутые ввиду
отсутствия нужных разрешений. Это образует мощный механизм для
идентификации событий секретности, представляющих актуальный ин-
терес, без анализа всего контрольного журнала.
.
- 5-18 -
Методология контроля
В данном разделе описывается, как функционирует подсистема
контроля, какие критерии используются при сборе данных, и как
требования контроля влияют на производительность системы.
Авторизации контроля
С подсистемой контроля связаны три авторизации:
configaudit, writeaudit и suspendaudit.
Авторизация configaudit позволяет устанавливать параметры
контроля для всех пользователей системы.
Авторизация writeaudit позволяет регистрировать специфичес-
кую информацию в контрольном журнале.
Авторизация suspendaudit отключает всякий контроль.
Источники контрольных записей
Контрольный журнал содержит содержит информацию о событиях
в системе, связанных с секретностью. Эффективный контроль охва-
тывает не только запросы на системные вызовы, поступающие от
пользовательских процессов, но и определенные события, такие,
как вход в систему, выход из системы, неудачные попытки регист-
рации. Эти события критичны для определения того, кто выполнял
доступ к системе, в какие моменты времени, с какого терминала, и
какие именно действия были выполнены. Неудачные попытки регист-
рации невозможно контролировать на уровне ядра, поскольку ему
неизвестно, что конкретно делает прикладная программа. Таким об-
разом, следует дать возможность генерировать контрольные записи
и некоторым утилитам, влияющих на секретность, например login.
Контрольные записи генерируются из трех источников (описы-
ваемых в последующих разделах):
* механизм контроля ядра
* надежные прикладные процессы
* авторизованные подсистемы
Механизм контроля ядра
Значительная часть контрольных записей, хранящихся в конт-
рольном журнале, генерируется механизмом контроля ядра. Этот
раздел подсистемы контроля генерирует записи в ответ на систем-
ные вызовы пользовательских процессов, отображаемые в события,
связанные с секретностью. Некоторые системные вызовы, например
open(S), отображаются в несколько событий секретности, в зависи-
мости от аргументов пользователя и от состояния открываемого
файла. Если open(S) вызывается с флагом O_CREAT, файл создается,
если он не существовал. Если задан флаг O_TRUNC, выполняется
.
- 5-19 -
усечение файла до нулевой длины, если он существует. Это показы-
вает, как вызов open(S) может отобразиться в одно из трех раз-
личных событий: Сделать объект доступным, Создание объекта или
Модификация объекта.
Важную роль в определении события играют также коды ошибок.
Ошибки при выполнении системных вызовов, указывающие, что доступ
или разрешение отвергнуты, равно как и проблемы потребления ре-
сурсов, отображаются в конкретные типы событий. Механизм контро-
ля ядра в конце системного вызова определяет, какому классу со-
бытий принадлежит вызов, и задали ли вы контроль этого события.
Более того, данный механизм может также применить дополнительные
критерии выбора, например, идентификатор пользователя или иден-
тификатор группы. Таким образом можно ограничить генерацию конт-
рольных записей, задав ее только для избранной группы пользова-
телей.
Надежные прикладные программы
Надежная вычислительная база (TCB) содержит несколько на-
дежных прикладных программ, необходимых для обеспечения безопас-
ной среды. Среди них - login, su и различные команды подсистемы
контроля. Для сокращения объема данных контроля, записанных в
контрольный журнал, и для повышения значимости информации в жур-
нале этим надежным прикладным программам разрешено писать прямо
на устройство контроля. Тем самым, например, login сможет занес-
ти контрольную запись о регистрации в системе прямо в контроль-
ный журнал, вместо того, чтобы представлять эту регистрацию в
виде набора системных вызовов, требуемых для завершения этой
процедуры.
Но недостаточно просто позволить надежным прикладным прог-
раммам писать на устройство контроля. В механизме контроля ядра
должен быть также предусмотрен способ подавления генерации конт-
рольных записей о системных вызовах, чтобы избежать загроможде-
ния контрольного журнала. Для этого существует авторизация
suspendaudit, о которой уже шла речь. Надежные прикладные прог-
раммы выполняются с этой авторизацией, что позволяет приостано-
вить контроль системных вызовов ядра для данного процесса и раз-
решить ему открывать устройство контроля и писать в него. Только
нескольким надежным прикладным программам разрешено это делать.
Обычный пользовательский процесс никогда не выполняется с авто-
ризацией suspendaudit. Механизмом авторизации управляет login,
используя ограниченные системные вызовы; этот механизм использу-
ет элементы базы данных защищенных паролей.
Авторизованные подсистемы
Третий способ генерации контрольных записей использует ав-
торизованные подсистемы, такие, как lp, cron, terminal и mem.
Иногда подсистема наталкивается на аномалии или проблемы, для
которых желательно составить информативную контрольную запись.
Однако подсистемы не имеют авторизации writeaudit и не могут за-
носить контрольные записи непосредственно в подсистему.
.
- 5-20 -
Вместо этого подсистемы формируют записи, как надежные
прикладные программы, и представляют их процессу демона контроля
через защищенный интерфейс. Демон контроля, являющийся надежной
прикладной программой, записывает контрольную запись в устройс-
тво контроля. Это позволяет процессам защищенных подсистем гене-
рировать осмысленные и информативные контрольные записи, не по-
лучая авторизации writeaudit.
Учитываемость в контроле
Подсистема контроля отслеживает системные события, связан-
ные с секретностью, и сопоставляет их с конкретными пользовате-
лями. Пользователи входят в систему через программу login. Эта
программа выполняет аутентификацию пользователя, чтобы опреде-
лить, разрешен ли ему доступ. Процедура регистрации в системе
усовершенствована таким образом, чтобы позволить контролировать
и успешные, и неудачные попытки регистрации. Когда регистрация
пользователя проходит успешно, login проставляет на пользова-
тельском процессе постоянный идентификатор - регистрационный
идентификатор пользователя (LUID). Независимо от количества сис-
темных вызовов setuid(S) и setgid(S), сделанных этим процессом,
LUID не изменяется. Для процесса и для пользователя обеспечива-
ется строгая учитываемость. Пользовательский процесс может по-
-прежнему выполнять системные вызовы setuid(S) и setgid(S), кото-
рые также контролируются. В контрольных записях указывается LUID
процесса наряду с эффективным и реальным идентификаторами поль-
зователя и группы для этого процесса.
Для того, чтобы обеспечить наличие всей требуемой информа-
ции о пользовательском процессе в выводе контроля, механизм
контроля ядра всегда отслеживает определенные системные вызовы -
так называемые обязательные системные вызовы. Они существенны
для сопровождения состояния процесса. Например, системный вызов
open(S) может задать относительное имя пути, такое, как
../newfile. Полное имя пути для файла зависит от текущего ката-
лога процесса, который устанавливается по системному вызову
chdir(S). Запись контроля, содержащую имя пути ../newfile, нель-
зя подвергнуть осмысленной редукции, не зная заранее об имени
текущего каталога.
Такая же проблема связана и с системным вызовом close(S).
Этот системный вызов для закрытия ранее открывавшегося файла
требует в качестве аргумента только дескриптор файла. Контроль-
ная запись close(S) потеряет смысл, если в ней не выводится имя
закрываемого объекта. Но если имя пути не было запомнено при от-
крытии файла, его невозможно предоставить для закрытия.
По этим причинам некоторые системные вызовы объявляются
обязательными и отслеживаются для всех процессов при включенном
контроле. Список обязательных системных вызовов относительно не-
велик; в него включены только те вызовы, которые обязательны для
аккуратного сопровождения состояния процесса: chdir(S),
chroot(S), open(S), close(S), fork(S), exit(S), exec(S),
setuid(S), setgid(S), dup(S) и fcntl(S).
.
- 5-21 -
Обязательный контроль не ограничивается только этой группой
системных вызовов. Событие регистрации является единственной
обязательной контрольной записью для надежных прикладных прог-
рамм. Когда пользователь регистрируется в системе, в регистраци-
онную запись заносится индикатор терминала, на котором была вы-
полнена регистрация. Если один и тот же пользователь зарегистри-
руется на нескольких терминалах в системе, его действия можно
отслеживать вплоть до конкретного терминала.
Типы событий контроля
Каждая контрольная запись, независимо от того, чем вызвано
ее появление, сопровождается отметкой о типе события. Для сис-
темных вызовов пользовательского процесса тип события определя-
ется механизмом контроля ядра, исходя из самого системного вызо-
ва и из его результата, как уже говорилось выше. При контроле
прикладной программы или подсистемы тип события устанавливает
процесс, формирующий контрольную запись. Этот тип события не из-
меняется ни устройством контроля, ни демоном контроля.
Типы событий имеют важное значение, так как они классифици-
руют события в системе, связанные с секретностью. И генерацией,
и редукцией контрольных записей можно управлять, основываясь на
типах событий. Например, если вы интересуетесь только пользова-
телями, входящими в систему и выходящими из нее, можно задать
этот тип события для сбора или редукции данных. Заметьте, что
если вы запрашиваете выборочный сбор событий, то информация о
событиях тех типов, которые вы исключили, не пишется в контроль-
ный журнал и, разумеется, не подлежит последующей редукции.
В подсистеме контроля имеется широкий диапазон типов собы-
тий, нарушающих равновесие между грануляцией и соответствующими
классами секретности. Поддерживаются следующие типы событий:
* Запуск и останов системы
* Вход в систему и выход из нее
* Создание и прекращение процесса
* Отображение объектов (например, файлов) в субъекты (нап-
ример, процессы)
* Сделать объект доступным
* Сделать объект недоступным
* Создание объекта
* Модификация объекта
* Удаление объекта
* Связь между процессами
* Изменения дискреционного доступа
* Отказы дискреционного доступа
* Недостаточная авторизация
* Отказы ресурса
* Действия Администратора системы/оператора
* Действия авторизованной подсистемы
.
- 5-22 -
* Действия секретной базы данных
* События подсистемы контроля
Вы можете, используя эти типы событий, выполнять выборочный
сбор и редукцию данных контроля. Интерфейс подсистемы контроля
позволяет составлять список типов событий либо для подсистемы
контроля, либо для программы редукции данных.
Подсистема контроля использует типы событий для того, чтобы
определить, нужно ли заносить контрольную запись в контрольный
журнал. Будучи Администратором контроля, вы полностью управляете
отбором событий для контроля.
Для управления контролем типов событий в подсистеме контро-
ля имеется глобальная системная маска событий контроля, которая
описана ниже. Подсистема контроля также обеспечивает маску типов
событий для каждого процесса в системе (также описана ниже). Обе
эти маски являются битовыми представлениями целочисленных значе-
ний типов событий, подлежащих контролю.
Системная маска событий контроля
Системная маска событий является глобальной для подсистемы
контроля. Ее можно установить с помощью sysadmsh и изменить в
процессе контроля, если возникает необходимость выбрать другой
набор событий. В системной маске событий каждому типу события
соответствует один бит; он устанавливается равным единице, если
контроль нужен. Это позволяет быстро проверять (с помощью бито-
вых операций), подлежит ли контролю только что созданная запись.
Подсистема контроля использует системную маску событий для вы-
числения пользовательских масок, когда при регистрации в системе
создается новый процесс.
Пользовательская маска событий и маска событий процесса
Вы можете отменить действие общесистемной маски событий для
любого пользователя, установив пользовательскую маску событий в
пользовательской строке защищенного пароля. Каждый процесс в
системе обладает маской событий процесса, которая говорит систе-
ме, что нужно контролировать для данного процесса. При регистра-
ции пользователя программа login анализирует пользовательскую
маску событий и устанавливает маску событий процесса для команд-
ного процессора регистрации следующим образом.
В пользовательской маске событий для каждого типа события
контроля предусмотрено одно из трех значений:
* всегда контролировать это событие
* никогда не контролировать это событие
* использовать системную маску событий контроля
Для каждого типа события контроля маска контроля процесса
устанавливается по пользовательской маске, если в ней указано,
что данное событие контролируется всегда или никогда. В против-
.
- 5-23 -
ном случае маска контроля процесса устанавливается по системной
маске событий контроля. В большинстве случаев в пользовательской
маске событий будет установлено третье значение для всех событий
контроля, в результате чего для этого пользователя будут приме-
няться системные параметры, принятые по умолчанию. Пользователь-
скую маску можно использовать для того, чтобы увеличивать или
уменьшать контролируемый объем информации о пользователях, кото-
рым вы соответственно меньше или больше доверяете по сравнению с
остальными.
Эффективный системный контроль
При использовании подсистемы контроля нужно следовать неко-
торым правилам. Подсистема спроектирована так, чтобы обеспечить
гибкую производительность и надежность и дать возможность соби-
рать те данные контроля, какие вы желаете. Генерация контрольной
записи поддерживает предварительную выборку событий контроля,
идентификаторов пользователей и идентификаторов групп. Предвари-
тельная выборка нужна, если вы по каким-то причинам хотите скон-
центрироваться на каком-либо конкретном пользователе или группе
пользователей (когда отдельные пользователи имеют обычай пытать-
ся обращаться к файлам, к которым им не разрешен доступ). Для
предварительной выборки можно также использовать типы событий -
например, контроль только событий входа в систему и выхода из
нее. Предварительная выборка, кроме того, дает экономию прост-
ранства на диске, так как уменьшается число контрольных записей,
заносимых подсистемой контроля в файлы сбора данных. Но в ис-
пользовании предварительной выборки есть и отрицательная сторо-
на. Если произошло нарушение секретности системы, и это событие
или совершивший его пользователь не был выбран для контроля, то
запись об этом действии будет утеряна.
Поэтому следует быть более консервативными - не делать
предварительную выборку событий контроля и пользователей/групп,
а вместо этого осуществлять полный контроль. В итоге любое про-
исшедшее событие, связанное с секретностью, будет зафиксировано
в контрольном журнале. Недостатки полного контроля: он занимает
много места на диске и увеличивает накладные расходы в системе.
Вы можете комбинировать полный контроль с пост-выборкой,
изучая только записи, представляющие интерес. Пост-выборка обес-
печивает выборочный анализ контрольного журнала на основе типов
событий, идентификаторов пользователей, идентификаторов групп и
имен объектов, а также момента генерации записи. В общем, под-
система контроля в сочетании с утилитой редукции/анализа данных
даст вам с помощью предварительной выборки гибкость при выборе
между системной производительностью и объемом пространства на
диске, а также удобство полного контроля в сочетании с пост-вы-
боркой.
Административные аспекты
Административное управление подсистемой контроля служит
ключом к эффективному контролю. Если тщательно установить и ак-
куратно пользоваться подсистемой контроля, она будет мощным
средством в деле поддержания секретности системы и идентификации
возникающих проблем. Эта подсистема спроектирована в довольно
завершенном виде в терминах охвата событий контроля - как со
стороны действий ядра, так и со стороны использования системных
утилит. Она спроектирована также для обеспечения надежности и
для минимизации влияния на производительность системы в целом.
.
- 5-24 -
Насколько хорошо подсистема удовлетворяет вашим целям, за-
висит от правильного административного управления системой. Вы
управляете согласованием надежности и производительности, ис-
пользуя параметры контроля. Неправильная установка может привес-
ти к низкой производительности, потере данных контроля или ко
всему сразу. Например, решающее значение имеет установка маски
событий контроля для управления типами событий, контролируемыми
подсистемой. Так, если предварительная выборка событий не вклю-
чает события регистрации, то проникновение в систему через ком-
мутируемую линию связи может остаться незамеченным. Поэтому
очень важно тщательно рассмотреть следующие три аспекта:
* задачи, связанные с производительностью
активности пользовательских процессов, с помощью системных вызо-
вов ядра. Каждый системный вызов ядра содержит строку в таблице
подсистемы, где указано, связан ли этот вызов с вопросами сек-
ретности, и если это так, то какому типу события он соответству-
ет. Кроме того, используется таблица кодов ошибок, позволяющая
классифицировать системные вызовы на конкретные события, связан-
ные с секретностью. Механизм контроля ядра выдает внутренний вы-
зов в драйвер устройства для занесения записи в контрольный жур-
нал.
Например, системный вызов open(S) классифицируется как со-
бытие Сделать объект доступным. Если пользователь blf выполняет
open(S) для /unix и делает это успешно, генерируется контрольная
запись об этом событии. Однако если системный вызов заканчивает-
ся неудачно из-за того, что blf запросил в open(S) доступ по за-
писи, не имея разрешения на запись в этот файл, это действие
классифицируется как событие Отказ дискреционного доступа для
blf и объекта /unix. Следовательно, системный вызов можно отоб-
разить в несколько типов событий, в зависимости от объекта, к
которому осуществляется доступ, и/или результата вызова. Поэтому
возникает возможность выборочного контроля системных вызовов, в
зависимости от типов событий, которые вы сделаете доступными.
Некоторые системные вызовы не относятся к секретности. Нап-
ример, getpid(S) получает идентификатор процесса и не определяет
событие, связанное с секретностью. Таким образом, этот системный
вызов не подлежит контролю.
Драйвер устройства контроля
Драйвер устройства контроля выполняет следующие функции:
прием контрольных записей от механизма контроля ядра и от надеж-
ных утилит; создание и запись промежуточных файлов контрольного
журнала; предоставление данных контрольного журнала демону конт-
роля для уплотнения; обеспечение выборочной генерации контроль-
ных записей на основе типов событий, идентификаторов пользовате-
лей и идентификаторов групп.
.
- 5-16 -
Драйвер устройства обеспечивает интерфейсы open(S),
close(S), read(S), write(S) и ioctl(S), как и прочие символьные
устройства. Однако устройство контроля может быть открыто только
процессами, обладающими авторизациями ядра configaudit и/или
writeaudit. Это ограничивает доступ к устройству контроля, раз-
решая его только для надежных утилит, таких как интерфейсы демо-
на контроля и Администратора контроля. В устройство контроля мо-
гут писать несколько процессов одновременно. Это устройство про-
изводит объединение записей в контрольный журнал. Читать с
устройства может только один процесс - демон контроля.
Драйвер устройства контроля ведет контрольный журнал в виде
набора файлов сбора данных контроля. Каждый раз, когда вы вклю-
чаете контроль, начинается новая сессия контроля. При ее запуске
подсистема создает файл сбора данных, в который заносятся конт-
рольные записи. Когда файл сбора данных достигает определенного
размера, установленного администратором, подсистема создает но-
вый файл сбора данных и начинает писать в него. Поэтому конт-
рольный журнал можно рассматривать как постоянно увеличивающийся
последовательный файл, даже если используется несколько файлов
сбора данных. Именно в таком виде контрольный журнал рассматри-
вается демоном контроля, потому что он читает с устройства и по-
лучает записи из контрольного журнала. При достижении конца фай-
ла сбора данных подсистема выполняет соответствующее переключе-
ние на новый файл сбора данных. Все это прозрачно для демона.
Демон контроля
Демон контроля auditd(ADM) - это надежная утилита, выполня-
ющаяся как фоновый демон-процесс при включении контроля. Этот
демон - единственный, кто читает с устройства контроля, которое
в свою очередь представляет демону блоки записей из файлов сбора
данных контроля. Демону безразлично, что контрольный журнал
расслаивается на множество файлов сбора данных. Драйвер устройс-
тва контроля удовлетворяет запросы на чтение, поступающие от де-
мона, и обрабатывает переключение и удаление файлов сбора данных
по мере надобности.
Главное предназначение демона состоит в предоставлении ме-
ханизма уплотнения данных и регистрации для сессии контроля. Де-
мон также выполняет функцию поддержки защищенных подсистем, поз-
воляя им писать в подсистему контрольные записи. В зависимости
от выбранного вами критерия формирования контрольных записей, в
системе может быть сгенерировано огромное количество данных
контроля. В типичном случае однопользовательской системы генера-
ция 200 килобайтов данных контроля за час не будет выглядеть не-
обычно. Поэтому демон предоставляет механизм уплотнения для сжа-
тия данных контроля в упакованный формат записи, которая сохра-
няется в файле уплотнения контроля.
Второй функцией демона является обеспечение журнального
файла, описывающего текущую сессию контроля. Журнальный файл со-
держит информацию о количестве контрольных записей, доступных в
уплотненных файлах вывода в сессии; время запуска и останова
сессии; а также другие индикаторы состояния сессии контроля. Как
только драйвер устройства контроля переключает файлы сбора дан-
.
- 5-17 -
ных при достижении ими размеров, установленных администратором,
демон может создать несколько уплотненных файлов, чтобы не до-
пустить увеличения одного файла до размеров, недоступных управ-
лению. Вы также это контролируете. Кроме того, уплотненные фай-
лы, записанные демоном, можно разместить в любом каталоге, опре-
деленном администратором. По этим причинам ведется журнальный
файл - чтобы иметь журнал с уплотненными файлами, которые можно
использовать для последующей редукции данных.
Третья функция демона контроля - выполнять роль программы
интерфейса с драйвером устройства контроля для занесения конт-
рольных записей из защищенных подсистем, не имеющих авторизации
writeaudit. Так как эти подсистемы не могут осуществлять доступ
непосредственно к драйверу устройства контроля, но могут образо-
вать интерфейс с демоном с соблюдением секретности, то демон вы-
полняет занесение контрольной записи прикладной программы в под-
систему.
Доступ к контролю через sysadmsh
sysadmsh предоставляет простые возможности для установки и
сопровождения подсистемы контроля. Это позволяет администратору
выполнять установку и инициализацию, модифицировать параметры
подсистемы, сопровождать подсистему (резервное дублирование,
восстановление и т.д.) и выполнять редукцию как общих, так и вы-
борочных данных контроля.
Средство редукции/анализа данных
sysadmsh также включает в себя утилиту редукции/анализа
данных, которая облегчает исследование контрольных журналов пре-
дыдущих сессий контроля или текущей сессии контроля. Используя
журнальный файл, созданный демоном контроля, утилита редукции
может идентифицировать все уплотненные файлы, нужные для редук-
ции сессии контроля. Так как уплотненные файлы имеют сжатый фор-
мат, программа редукции содержит подпрограммы, необходимые для
развертывания файлов.
Для обеспечения эффективного анализа данных контроля утили-
та редукции позволяет задавать для выборочной редукции данных
определенные типы событий, идентификаторы пользователей, иденти-
фикаторы групп и имена объектов. Более того, вы можете задать
интервал времени, в течение которого должен производиться поиск
записей, удовлетворяющих выбранному критерию. Если какая-либо
запись не попадает в этот интервал, она отбрасывается в данной
редукции.
Например, вы можете выполнять редукцию данных, выбирая со-
бытие Отказа DAC для пользователя с идентификатором blf, ведуще-
го поиск объекта /unix. Будут распечатаны только те записи, ко-
торые отражают попытки доступа blf к /unix, отвергнутые ввиду
отсутствия нужных разрешений. Это образует мощный механизм для
идентификации событий секретности, представляющих актуальный ин-
терес, без анализа всего контрольного журнала.
.
- 5-18 -
Методология контроля
В данном разделе описывается, как функционирует подсистема
контроля, какие критерии используются при сборе данных, и как
требования контроля влияют на производительность системы.
Авторизации контроля
С подсистемой контроля связаны три авторизации:
configaudit, writeaudit и suspendaudit.
Авторизация configaudit позволяет устанавливать параметры
контроля для всех пользователей системы.
Авторизация writeaudit позволяет регистрировать специфичес-
кую информацию в контрольном журнале.
Авторизация suspendaudit отключает всякий контроль.
Источники контрольных записей
Контрольный журнал содержит содержит информацию о событиях
в системе, связанных с секретностью. Эффективный контроль охва-
тывает не только запросы на системные вызовы, поступающие от
пользовательских процессов, но и определенные события, такие,
как вход в систему, выход из системы, неудачные попытки регист-
рации. Эти события критичны для определения того, кто выполнял
доступ к системе, в какие моменты времени, с какого терминала, и
какие именно действия были выполнены. Неудачные попытки регист-
рации невозможно контролировать на уровне ядра, поскольку ему
неизвестно, что конкретно делает прикладная программа. Таким об-
разом, следует дать возможность генерировать контрольные записи
и некоторым утилитам, влияющих на секретность, например login.
Контрольные записи генерируются из трех источников (описы-
ваемых в последующих разделах):
* механизм контроля ядра
* надежные прикладные процессы
* авторизованные подсистемы
Механизм контроля ядра
Значительная часть контрольных записей, хранящихся в конт-
рольном журнале, генерируется механизмом контроля ядра. Этот
раздел подсистемы контроля генерирует записи в ответ на систем-
ные вызовы пользовательских процессов, отображаемые в события,
связанные с секретностью. Некоторые системные вызовы, например
open(S), отображаются в несколько событий секретности, в зависи-
мости от аргументов пользователя и от состояния открываемого
файла. Если open(S) вызывается с флагом O_CREAT, файл создается,
если он не существовал. Если задан флаг O_TRUNC, выполняется
.
- 5-19 -
усечение файла до нулевой длины, если он существует. Это показы-
вает, как вызов open(S) может отобразиться в одно из трех раз-
личных событий: Сделать объект доступным, Создание объекта или
Модификация объекта.
Важную роль в определении события играют также коды ошибок.
Ошибки при выполнении системных вызовов, указывающие, что доступ
или разрешение отвергнуты, равно как и проблемы потребления ре-
сурсов, отображаются в конкретные типы событий. Механизм контро-
ля ядра в конце системного вызова определяет, какому классу со-
бытий принадлежит вызов, и задали ли вы контроль этого события.
Более того, данный механизм может также применить дополнительные
критерии выбора, например, идентификатор пользователя или иден-
тификатор группы. Таким образом можно ограничить генерацию конт-
рольных записей, задав ее только для избранной группы пользова-
телей.
Надежные прикладные программы
Надежная вычислительная база (TCB) содержит несколько на-
дежных прикладных программ, необходимых для обеспечения безопас-
ной среды. Среди них - login, su и различные команды подсистемы
контроля. Для сокращения объема данных контроля, записанных в
контрольный журнал, и для повышения значимости информации в жур-
нале этим надежным прикладным программам разрешено писать прямо
на устройство контроля. Тем самым, например, login сможет занес-
ти контрольную запись о регистрации в системе прямо в контроль-
ный журнал, вместо того, чтобы представлять эту регистрацию в
виде набора системных вызовов, требуемых для завершения этой
процедуры.
Но недостаточно просто позволить надежным прикладным прог-
раммам писать на устройство контроля. В механизме контроля ядра
должен быть также предусмотрен способ подавления генерации конт-
рольных записей о системных вызовах, чтобы избежать загроможде-
ния контрольного журнала. Для этого существует авторизация
suspendaudit, о которой уже шла речь. Надежные прикладные прог-
раммы выполняются с этой авторизацией, что позволяет приостано-
вить контроль системных вызовов ядра для данного процесса и раз-
решить ему открывать устройство контроля и писать в него. Только
нескольким надежным прикладным программам разрешено это делать.
Обычный пользовательский процесс никогда не выполняется с авто-
ризацией suspendaudit. Механизмом авторизации управляет login,
используя ограниченные системные вызовы; этот механизм использу-
ет элементы базы данных защищенных паролей.
Авторизованные подсистемы
Третий способ генерации контрольных записей использует ав-
торизованные подсистемы, такие, как lp, cron, terminal и mem.
Иногда подсистема наталкивается на аномалии или проблемы, для
которых желательно составить информативную контрольную запись.
Однако подсистемы не имеют авторизации writeaudit и не могут за-
носить контрольные записи непосредственно в подсистему.
.
- 5-20 -
Вместо этого подсистемы формируют записи, как надежные
прикладные программы, и представляют их процессу демона контроля
через защищенный интерфейс. Демон контроля, являющийся надежной
прикладной программой, записывает контрольную запись в устройс-
тво контроля. Это позволяет процессам защищенных подсистем гене-
рировать осмысленные и информативные контрольные записи, не по-
лучая авторизации writeaudit.
Учитываемость в контроле
Подсистема контроля отслеживает системные события, связан-
ные с секретностью, и сопоставляет их с конкретными пользовате-
лями. Пользователи входят в систему через программу login. Эта
программа выполняет аутентификацию пользователя, чтобы опреде-
лить, разрешен ли ему доступ. Процедура регистрации в системе
усовершенствована таким образом, чтобы позволить контролировать
и успешные, и неудачные попытки регистрации. Когда регистрация
пользователя проходит успешно, login проставляет на пользова-
тельском процессе постоянный идентификатор - регистрационный
идентификатор пользователя (LUID). Независимо от количества сис-
темных вызовов setuid(S) и setgid(S), сделанных этим процессом,
LUID не изменяется. Для процесса и для пользователя обеспечива-
ется строгая учитываемость. Пользовательский процесс может по-
-прежнему выполнять системные вызовы setuid(S) и setgid(S), кото-
рые также контролируются. В контрольных записях указывается LUID
процесса наряду с эффективным и реальным идентификаторами поль-
зователя и группы для этого процесса.
Для того, чтобы обеспечить наличие всей требуемой информа-
ции о пользовательском процессе в выводе контроля, механизм
контроля ядра всегда отслеживает определенные системные вызовы -
так называемые обязательные системные вызовы. Они существенны
для сопровождения состояния процесса. Например, системный вызов
open(S) может задать относительное имя пути, такое, как
../newfile. Полное имя пути для файла зависит от текущего ката-
лога процесса, который устанавливается по системному вызову
chdir(S). Запись контроля, содержащую имя пути ../newfile, нель-
зя подвергнуть осмысленной редукции, не зная заранее об имени
текущего каталога.
Такая же проблема связана и с системным вызовом close(S).
Этот системный вызов для закрытия ранее открывавшегося файла
требует в качестве аргумента только дескриптор файла. Контроль-
ная запись close(S) потеряет смысл, если в ней не выводится имя
закрываемого объекта. Но если имя пути не было запомнено при от-
крытии файла, его невозможно предоставить для закрытия.
По этим причинам некоторые системные вызовы объявляются
обязательными и отслеживаются для всех процессов при включенном
контроле. Список обязательных системных вызовов относительно не-
велик; в него включены только те вызовы, которые обязательны для
аккуратного сопровождения состояния процесса: chdir(S),
chroot(S), open(S), close(S), fork(S), exit(S), exec(S),
setuid(S), setgid(S), dup(S) и fcntl(S).
.
- 5-21 -
Обязательный контроль не ограничивается только этой группой
системных вызовов. Событие регистрации является единственной
обязательной контрольной записью для надежных прикладных прог-
рамм. Когда пользователь регистрируется в системе, в регистраци-
онную запись заносится индикатор терминала, на котором была вы-
полнена регистрация. Если один и тот же пользователь зарегистри-
руется на нескольких терминалах в системе, его действия можно
отслеживать вплоть до конкретного терминала.
Типы событий контроля
Каждая контрольная запись, независимо от того, чем вызвано
ее появление, сопровождается отметкой о типе события. Для сис-
темных вызовов пользовательского процесса тип события определя-
ется механизмом контроля ядра, исходя из самого системного вызо-
ва и из его результата, как уже говорилось выше. При контроле
прикладной программы или подсистемы тип события устанавливает
процесс, формирующий контрольную запись. Этот тип события не из-
меняется ни устройством контроля, ни демоном контроля.
Типы событий имеют важное значение, так как они классифици-
руют события в системе, связанные с секретностью. И генерацией,
и редукцией контрольных записей можно управлять, основываясь на
типах событий. Например, если вы интересуетесь только пользова-
телями, входящими в систему и выходящими из нее, можно задать
этот тип события для сбора или редукции данных. Заметьте, что
если вы запрашиваете выборочный сбор событий, то информация о
событиях тех типов, которые вы исключили, не пишется в контроль-
ный журнал и, разумеется, не подлежит последующей редукции.
В подсистеме контроля имеется широкий диапазон типов собы-
тий, нарушающих равновесие между грануляцией и соответствующими
классами секретности. Поддерживаются следующие типы событий:
* Запуск и останов системы
* Вход в систему и выход из нее
* Создание и прекращение процесса
* Отображение объектов (например, файлов) в субъекты (нап-
ример, процессы)
* Сделать объект доступным
* Сделать объект недоступным
* Создание объекта
* Модификация объекта
* Удаление объекта
* Связь между процессами
* Изменения дискреционного доступа
* Отказы дискреционного доступа
* Недостаточная авторизация
* Отказы ресурса
* Действия Администратора системы/оператора
* Действия авторизованной подсистемы
.
- 5-22 -
* Действия секретной базы данных
* События подсистемы контроля
Вы можете, используя эти типы событий, выполнять выборочный
сбор и редукцию данных контроля. Интерфейс подсистемы контроля
позволяет составлять список типов событий либо для подсистемы
контроля, либо для программы редукции данных.
Подсистема контроля использует типы событий для того, чтобы
определить, нужно ли заносить контрольную запись в контрольный
журнал. Будучи Администратором контроля, вы полностью управляете
отбором событий для контроля.
Для управления контролем типов событий в подсистеме контро-
ля имеется глобальная системная маска событий контроля, которая
описана ниже. Подсистема контроля также обеспечивает маску типов
событий для каждого процесса в системе (также описана ниже). Обе
эти маски являются битовыми представлениями целочисленных значе-
ний типов событий, подлежащих контролю.
Системная маска событий контроля
Системная маска событий является глобальной для подсистемы
контроля. Ее можно установить с помощью sysadmsh и изменить в
процессе контроля, если возникает необходимость выбрать другой
набор событий. В системной маске событий каждому типу события
соответствует один бит; он устанавливается равным единице, если
контроль нужен. Это позволяет быстро проверять (с помощью бито-
вых операций), подлежит ли контролю только что созданная запись.
Подсистема контроля использует системную маску событий для вы-
числения пользовательских масок, когда при регистрации в системе
создается новый процесс.
Пользовательская маска событий и маска событий процесса
Вы можете отменить действие общесистемной маски событий для
любого пользователя, установив пользовательскую маску событий в
пользовательской строке защищенного пароля. Каждый процесс в
системе обладает маской событий процесса, которая говорит систе-
ме, что нужно контролировать для данного процесса. При регистра-
ции пользователя программа login анализирует пользовательскую
маску событий и устанавливает маску событий процесса для команд-
ного процессора регистрации следующим образом.
В пользовательской маске событий для каждого типа события
контроля предусмотрено одно из трех значений:
* всегда контролировать это событие
* никогда не контролировать это событие
* использовать системную маску событий контроля
Для каждого типа события контроля маска контроля процесса
устанавливается по пользовательской маске, если в ней указано,
что данное событие контролируется всегда или никогда. В против-
.
- 5-23 -
ном случае маска контроля процесса устанавливается по системной
маске событий контроля. В большинстве случаев в пользовательской
маске событий будет установлено третье значение для всех событий
контроля, в результате чего для этого пользователя будут приме-
няться системные параметры, принятые по умолчанию. Пользователь-
скую маску можно использовать для того, чтобы увеличивать или
уменьшать контролируемый объем информации о пользователях, кото-
рым вы соответственно меньше или больше доверяете по сравнению с
остальными.
Эффективный системный контроль
При использовании подсистемы контроля нужно следовать неко-
торым правилам. Подсистема спроектирована так, чтобы обеспечить
гибкую производительность и надежность и дать возможность соби-
рать те данные контроля, какие вы желаете. Генерация контрольной
записи поддерживает предварительную выборку событий контроля,
идентификаторов пользователей и идентификаторов групп. Предвари-
тельная выборка нужна, если вы по каким-то причинам хотите скон-
центрироваться на каком-либо конкретном пользователе или группе
пользователей (когда отдельные пользователи имеют обычай пытать-
ся обращаться к файлам, к которым им не разрешен доступ). Для
предварительной выборки можно также использовать типы событий -
например, контроль только событий входа в систему и выхода из
нее. Предварительная выборка, кроме того, дает экономию прост-
ранства на диске, так как уменьшается число контрольных записей,
заносимых подсистемой контроля в файлы сбора данных. Но в ис-
пользовании предварительной выборки есть и отрицательная сторо-
на. Если произошло нарушение секретности системы, и это событие
или совершивший его пользователь не был выбран для контроля, то
запись об этом действии будет утеряна.
Поэтому следует быть более консервативными - не делать
предварительную выборку событий контроля и пользователей/групп,
а вместо этого осуществлять полный контроль. В итоге любое про-
исшедшее событие, связанное с секретностью, будет зафиксировано
в контрольном журнале. Недостатки полного контроля: он занимает
много места на диске и увеличивает накладные расходы в системе.
Вы можете комбинировать полный контроль с пост-выборкой,
изучая только записи, представляющие интерес. Пост-выборка обес-
печивает выборочный анализ контрольного журнала на основе типов
событий, идентификаторов пользователей, идентификаторов групп и
имен объектов, а также момента генерации записи. В общем, под-
система контроля в сочетании с утилитой редукции/анализа данных
даст вам с помощью предварительной выборки гибкость при выборе
между системной производительностью и объемом пространства на
диске, а также удобство полного контроля в сочетании с пост-вы-
боркой.
Административные аспекты
Административное управление подсистемой контроля служит
ключом к эффективному контролю. Если тщательно установить и ак-
куратно пользоваться подсистемой контроля, она будет мощным
средством в деле поддержания секретности системы и идентификации
возникающих проблем. Эта подсистема спроектирована в довольно
завершенном виде в терминах охвата событий контроля - как со
стороны действий ядра, так и со стороны использования системных
утилит. Она спроектирована также для обеспечения надежности и
для минимизации влияния на производительность системы в целом.
.
- 5-24 -
Насколько хорошо подсистема удовлетворяет вашим целям, за-
висит от правильного административного управления системой. Вы
управляете согласованием надежности и производительности, ис-
пользуя параметры контроля. Неправильная установка может привес-
ти к низкой производительности, потере данных контроля или ко
всему сразу. Например, решающее значение имеет установка маски
событий контроля для управления типами событий, контролируемыми
подсистемой. Так, если предварительная выборка событий не вклю-
чает события регистрации, то проникновение в систему через ком-
мутируемую линию связи может остаться незамеченным. Поэтому
очень важно тщательно рассмотреть следующие три аспекта:
* задачи, связанные с производительностью