вения в систему. Можно задать максимальное число неудачных попы-
ток регистрации, которые обычно связаны с попытками угадать па-
.
- 5-13 -
роль бюджета. Терминалы, для которых превышено максимально
допустимое число попыток, будут заблокированы; снимать блокиров-
ку должен Администратор бюджетов. Кроме того, можно задать ин-
тервал времени, который должен пройти между попытками регистра-
ции, что также может помочь пресечь попытки угадать пароль.
(Аналогичные ограничения можно ввести для бюджетов, отличных от
терминалов.) О том, как изменять или проверять ограничения для
терминала, см. раздел "Управление регистрацией терминала" в гла-
ве "Административное управление пользовательскими бюджетами"
настоящего руководства.
Активность начальной регистрации
Как и в случае терминалов, у пользовательских бюджетов есть
параметры, связанные с числом попыток регистрации и интервалом
для повторной попытки, которые относятся к регистрации в бюдже-
те, а не в терминале. О том, как изменять или проверять эти ог-
раничения, см. раздел "Изменение ограничений при регистрации,
принятых по умолчанию" в главе "Административное управление
пользовательскими бюджетами" настоящего руководства.
.
- 5-14 -
ИСПОЛЬЗОВАНИЕ ПОДСИСТЕМЫ КОНТРОЛЯ
Подсистема контроля регистрирует события в системе, связан-
ные с секретностью, записывая их в контрольный журнал, который
затем можно просмотреть. В контрольных журналах, выдаваемых под-
системой, можно фиксировать проникновение в систему и неправиль-
ное использование ресурсов. Подсистема контроля спроектирована в
соответствии с задачами контроля, определяемыми Национальным
центром защиты данных компьютеров США.
Контроль позволяет просматривать собранные данные для изу-
чения образцов доступа к объектам и наблюдения за действиями от-
дельных пользователей и их процессов. Попытки нарушения защиты и
механизмов авторизации контролируются. Подсистема контроля дает
высокую степень гарантии обнаружения попыток обойти механизмы
обеспечения безопасности. Поскольку события, связанные с секрет-
ностью, контролируются и поддаются учету вплоть до выявления
конкретного пользователя, подсистема контроля служит сдерживаю-
щим средством для пользователей, пытающихся неправильно восполь-
зоваться системой.
Подсистема контроля использует системные вызовы и утилиты
для классификации действий пользователей, подразделяя их на типы
событий. Это можно использовать для выборочной генерации и ре-
дукции контроля. Один из этих типов событий, Отказ дискреционно-
го доступа (DAC), регистрирует попытки такого использования объ-
ектов, которое не допускается разрешениями для этого объекта.
Например, если пользовательский процесс пытается писать в файл
"только для чтения", регистрируется событие Отказа DAC, показы-
вающее, что процесс пытался произвести запись в файл, на что у
него не было права. Если просмотреть контрольный журнал, то лег-
ко будет заметить повторяющиеся попытки доступа к файлам, на ко-
торые не выданы разрешения.
Для эффективности данных контроля существенна возможность
учета пользователей, выполняющих действия, подлежащие контролю.
Когда пользователи пытаются войти в систему, они должны пройти
процесс идентификации и аутентификации, прежде чем им будет пре-
доставлен доступ в систему. Механизм секретности снабжает каждый
процесс, создаваемый пользователем, постоянным индикатором иден-
тичности - регистрационным идентификатором пользователя (LUID).
Этот идентификатор сохраняется невзирая на переходы от одного
пользовательского бюджета к другому с помощью таких команд, как
su(C). Каждая контрольная запись, генерируемая подсистемой, со-
держит LUID наряду с эффективным и реальным идентификаторами
пользователя и группы для процесса. В итоге оказывается возмож-
ным строгий учет действий пользователей.
Подсистема контроля управляется Администратором контроля.
Будучи Администратором контроля, вы обладаете полным контролем
над событиями, выбранными для генерации контрольных записей, над
значениями параметров подсистемы контроля и над последующей ре-
дукцией и анализом данных контроля.
.
- 5-15 -
Компоненты подсистемы контроля
Подсистема контроля состоит из четырех главных компонентов:
* Механизм контроля ядра
* Драйвер устройства контроля (/dev/audit)
* Демон уплотнения данных контроля - auditd(ADM)
* Интерфейс контроля sysadmsh
Существует несколько надежных системных утилит, которые,
хотя на самом деле и не являются собственно частью подсистемы
контроля, отвечают за занесение контрольных записей в контроль-
ный журнал (например, login(M)).
Механизм контроля ядра
Механизм контроля ядра является центральным в подсистеме
контроля. Этот механизм генерирует контрольные записи, исходя из
активности пользовательских процессов, с помощью системных вызо-
вов ядра. Каждый системный вызов ядра содержит строку в таблице
подсистемы, где указано, связан ли этот вызов с вопросами сек-
ретности, и если это так, то какому типу события он соответству-
ет. Кроме того, используется таблица кодов ошибок, позволяющая
классифицировать системные вызовы на конкретные события, связан-
ные с секретностью. Механизм контроля ядра выдает внутренний вы-
зов в драйвер устройства для занесения записи в контрольный жур-
нал.
Например, системный вызов 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 также включает в себя утилиту редукции/анализа
данных, которая облегчает исследование контрольных журналов пре-
дыдущих сессий контроля или текущей сессии контроля. Используя
