журнальный файл, созданный демоном контроля, утилита редукции
может идентифицировать все уплотненные файлы, нужные для редук-
ции сессии контроля. Так как уплотненные файлы имеют сжатый фор-
мат, программа редукции содержит подпрограммы, необходимые для
развертывания файлов.
Для обеспечения эффективного анализа данных контроля утили-
та редукции позволяет задавать для выборочной редукции данных
определенные типы событий, идентификаторы пользователей, иденти-
фикаторы групп и имена объектов. Более того, вы можете задать
интервал времени, в течение которого должен производиться поиск
записей, удовлетворяющих выбранному критерию. Если какая-либо
запись не попадает в этот интервал, она отбрасывается в данной
редукции.
Например, вы можете выполнять редукцию данных, выбирая со-
бытие Отказа 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 -
Обязательный контроль не ограничивается только этой группой
системных вызовов. Событие регистрации является единственной
обязательной контрольной записью для надежных прикладных прог-
рамм. Когда пользователь регистрируется в системе, в регистраци-
онную запись заносится индикатор терминала, на котором была вы-
полнена регистрация. Если один и тот же пользователь зарегистри-
руется на нескольких терминалах в системе, его действия можно
отслеживать вплоть до конкретного терминала.
Типы событий контроля
Каждая контрольная запись, независимо от того, чем вызвано
ее появление, сопровождается отметкой о типе события. Для сис-
темных вызовов пользовательского процесса тип события определя-
ется механизмом контроля ядра, исходя из самого системного вызо-
ва и из его результата, как уже говорилось выше. При контроле
прикладной программы или подсистемы тип события устанавливает
процесс, формирующий контрольную запись. Этот тип события не из-
меняется ни устройством контроля, ни демоном контроля.
Типы событий имеют важное значение, так как они классифици-
руют события в системе, связанные с секретностью. И генерацией,
и редукцией контрольных записей можно управлять, основываясь на
типах событий. Например, если вы интересуетесь только пользова-
телями, входящими в систему и выходящими из нее, можно задать
этот тип события для сбора или редукции данных. Заметьте, что
если вы запрашиваете выборочный сбор событий, то информация о
событиях тех типов, которые вы исключили, не пишется в контроль-
ный журнал и, разумеется, не подлежит последующей редукции.
В подсистеме контроля имеется широкий диапазон типов собы-
тий, нарушающих равновесие между грануляцией и соответствующими
классами секретности. Поддерживаются следующие типы событий:
* Запуск и останов системы
* Вход в систему и выход из нее
* Создание и прекращение процесса
* Отображение объектов (например, файлов) в субъекты (нап-
ример, процессы)
* Сделать объект доступным
* Сделать объект недоступным
* Создание объекта
* Модификация объекта
* Удаление объекта
* Связь между процессами
* Изменения дискреционного доступа
* Отказы дискреционного доступа
* Недостаточная авторизация
