Жанр: Учеба
SCO: Пособие администратора системы Unix
...бразом можно ограничить генерацию контрольных
записей, задав ее только для избранной группы пользователей.
Надежные прикладные программы
Надежная вычислительная база (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 -
Насколько хорошо подсистема удовлетворяет вашим целям, зависит
от правильного административного управления системой. Вы
управляете согласованием надежности и производительности, используя
параметры контроля. Неправильная установка может привести
к низкой производительности, потере данных контроля или ко
всему сразу. Например, решающее значение имеет установка маски
событий контроля для управления типами событий, контролируемыми
подсистемой. Так, если предварительная выборка событий не включает
события регистрации, то проникновение в систему через коммутируемую
линию связи может остаться незамеченным. Поэтому
очень важно тщательно рассмотреть следующие три аспекта:
* задачи, связанные с производительностью
* задачи, связанные с надежностью
* требования к контрольному журналу
Задачи, связанные с производительностью
При оценке влияния подсистемы контроля на производительность
системы важно продумать, какие действия должна выполнять
подсистема. Драйвер устройства подсистемы контроля - это главное
место сбора контрольных записей из всевозможных источников; он
отвечает за внесение этих записей в контрольный журнал. Драйвер
выполняет запись в файл сбора данных, совместно используемый
всеми процессами, контролируемыми в системе. Это напоминает систему
резервирования мест на самолетах, где множество клерков выполняют
доступ к общей базе данных. Должны быть предусмотрены
механизмы блокировки, чтобы не допустить смешивания контрольных
записей и обеспечить совместимость базы данных. То же касается и
файлов сбора данных подсистемы контроля.
Механизм внутренней буферизации и стратегия записи (writebehind)
пытаются минимизировать воздействие многократной одновременной
записи на файлы сбора данных. Это позволяет подсистеме
обслуживать контрольные записи от процессов и прикладных программ
в то время, как параллельно идет запись в файлы сбора данных.
Вы можете настроить этот механизм, учитывая, как интенсивно
используется буферизация и как часто идет запись в файл сбора
данных.
Задачи, связанные с надежностью
Так же, как и производительность системы, важна надежность
выдаваемого контрольного журнала. В традиционных системах UNIX
нет возможности сохранить целостность файловой системы в результате
фатального сбоя системы. Это вызвано тем фактом, что ввод-вывод
выполняется с помощью пула буферов, в которые запись
(главным образом) ведется асинхронно. Так, изменения, внесенные
в файлы, на самом деле могут оказаться не записанными на диск
при фатальном сбое системы.
Это грустно, так как события, приводящие к фатальному сбою
системы, представляют для вас наибольший интерес с точки зрения
контроля. Очень хотелось бы минимизировать какую бы то ни было
потенциальную потерю данных из подсистемы контроля в результате
- 5-25 -
фатального сбоя системы. Для этого подсистема контроля использует
механизм, называемый синхронным вводом-выводом, который выполняет
немедленное обновление буферов сбора данных контроля и
индексных дескрипторов файлов сбора данных, когда происходит их
изменение. Это сводит к минимуму возможные потери данных в результате
фатального сбоя системы.
Существует прямая связь между степенью надежности данных и
производительностью подсистемы контроля. Контрольные записи, генерируемые
механизмом контроля ядра, надежными прикладными программами
и защищенными подсистемами, обычно имеют длину 40-60
байт. Если каждая запись пишется на диск синхронно, как только
она передана подсистеме, результатом будет низкая производительность;
система ввода-вывода переполняется из-за высокой скорости
генерации записей. Выход состоит в том, чтобы буферизовать записи
и писать их в контрольный журнал вместе через назначенные интервалы
времени. Эти интервалы можно определить по истекшему
времени или по пороговой величине накопленных данных. И здесь
также выбор зависит от вас.
Требования к контрольному журналу
И, наконец, последнее, что важно для административного управления
подсистемой контроля, - определить, что именно нужно
контролировать. Можно использовать возможности предварительной
выборки при генерации записей, чтобы контрольный журнал сконцентрировался
на одном или нескольких событиях. Например, система
может использоваться всего лишь маленькой группой людей, а по
ночам простаивать. Кроме того, в нерабочее время предоставляются
несколько коммутируемых линий связи. Возможно, вас интересует
только учет того, кто и когда пользуется системой. В этом
случае предварительную выборку можно использовать только для отслеживания
событий входа в систему и выхода из нее. Попытки проникновения
в систему со стороны неавторизованных пользователей
будут зафиксированы как неудачные попытки регистрации.
Контроль можно также сосредоточить на конкретных пользователях
или группах пользователей. Это позволит вам сконцентрироваться
на лицах, подозреваемых в нарушении стратегии секретности.
Чем меньше запрошено контроля, тем меньше подсистема контроля
влияет на производительность системы. Полный контроль приводит
к созданию пространной и подробной записи о системных событиях,
но он требует и больше ресурсов для работы. Однако чаще
оказывается удобнее зарегистрировать события и использовать
средства редукции, чтобы потом отбросить ненужные записи, чем
отказаться от сбора записей, действительно необходимых для анализа
проблемы. Это решение зависит от степени секретности, которую
вы намерены соблюсти.
Важно понять определение сессии контроля по отношению к
подсистеме. Предполагается, что сессия соответствует интервалу
времени с момента загрузки системы до момента ее выключения. Для
сокращения объема записываемых в контрольный журнал данных в качестве
одной из задач при проектировании подсистемы была установлена
минимизация размера каждой контрольной записи. Следовательно,
состояние процесса определяется последовательностью
контрольных записей, а не указывается целиком в каждой записи.
- 5-26 -
При таком подходе экономия места и времени оказывается значительной,
но это требует аккуратного административного управления
во избежание ловушек.
Если отключить подсистему контроля во время работы системы,
а затем вновь включить, будет создана новая сессия. Сессия определяется
как последовательность файлов сбора данных и уплотненных
файлов, содержащих контрольные записи, связанные с конкретным
интервалом времени. Это может привести к созданию двух (а
возможно, и больше) наборов файлов контроля в одном жизненном
цикле системы. Некоторые процессы, контролируемые во второй или
последующей сессии, могут оказаться созданными во время первой
сессии. Следовательно, сессия может не содержать все соответствующее
состояние процесса, нужное для какого-либо процесса. В
свою очередь, это может вызвать неполную редукцию записей. Это
относится главным образом к именам файлов, причем как правило -
только к относительным именам файлов (а не абсолютным). Этого
можно избежать, если выключать контроль только после останова
системы.
Процедуры контроля
В данном разделе описывается, как устанавливать, инициировать,
модифицировать и прекращать контроль системы. Доступ к
каждой из этих функций осуществляется через sysadmsh. Выход на
верхний уровень функций контроля производится выбором
System-"Audit; это следующие функции:
Enable/Disable Инициирование и прекращение контроля
Collection Выбор критерия контроля
Формирование конфигурации подсистемы и управ-
ление контролируемыми событиями и пользовате-
лями. Кроме того, можно управлять параметрами
установки, влияющими на производительность и
надежность подсистемы и ее данные
Report Редукция данных контроля и составление отчетов
Создание и сохранение выборочных файлов ре-
дукции, редукция сессий контроля с помощью
файлов сбора данных и удаление сокращенных
файлов после того, как они становятся ненуж-
ными
Files Сопровождение файла контрольных записей
Проверка сессий контроля, накопленных в сис-
теме, архивирование сессий контроля на ре-
зервном носителе, восстановление ранее сохра-
ненных сессий контроля, удаление ненужных
сессий контроля, пуск и останов контроля по
мере надобности
- 5-27 -
Процедура контроля состоит из трех этапов, описанных в последующих
разделах:
1. Установка схемы сбора данных
2. Включение контроля
3. Генерация контрольных отчетов
Установка схемы сбора данных
Чтобы задать, какие данные следует собирать и где их следует
хранить, сделайте в sysadmsh следующий выбор:
System-"Audit-"Collection
На экране появятся следующие элементы для выбора:
Directories Каталоги файлов сбора данных контроля и уп-
лотненных файлов
Events Системная маска типов событий
IDs Выбор контроля пользователя и группы
Parameters Параметры подсистемы контроля
Summary Распечатка статистики текущей сессии контроля
Выберите, какую информацию вы хотите поставлять; каждый выбор
описан в одном из последующих разделов. Информация о сборе
данных, заданная вами, записывается в файл параметров. Система
поставляется с файлом параметров, заданным по умолчанию, но вы
должны модифицировать его, чтобы он удовлетворял вашим требованиям.
Инициированная подсистема контролирует события в соответствии
с содержимым файла параметров до тех пор, пока параметры не
будут модифицированы, или до прекращения контроля, или до останова
системы. Заметим, что некоторые параметры можно модифицировать
в ходе контроля, а другие действительны только в момент
инициирования контроля. По мере описания очередной области конфигурации
отмечаются статические и динамические величины.
Каталоги контроля
Файлы сбора данных, генерируемые подсистемой контроля, и
уплотненные файлы, генерируемые демоном контроля, записываются в
заданные вами каталоги. Сессия контроля может содержать файлы,
записанные во множество различных каталогов. К концу сессии остаются
только уплотненные файлы, так как файлы сбора данных удаляются
подсистемой, когда они прочитаны демоном контроля. Вам не
нужно отслеживать каталоги, в которые записываются файлы, поскольку
эта информация имеется в журнальном файле сессии.
Вы можете увеличить производительность системы, поместив
каталоги контроля в файловую систему, расположенную на отдельном
физическом устройстве от остальных файловых систем. Это уменьшит
соперничество за ресурсы диска. Кроме того, контроль требует
значительного пространства, даже с учетом уплотнения. Когда мес.
- 5-28 -
та на диске становится мало, подсистема выдает предупреждение;
если свободного пространства в файловой системе становится слишком
мало, то подсистема выключает контроль. По этой причине подсистема
и демон поддерживают несколько каталогов. При возникновении
ошибки во время записи в каталог или при исчерпании места
на диске подсистема и демон пытаются воспользоваться альтернативными
каталогами, чтобы продолжить работу.
Каждое имя файла следует вводить с указанием абсолютного
имени пути. Число каталогов, которые вы можете определить, ничем
не ограничено. Если никакие каталоги не заданы, подсистема и демон
создают все файлы в корневой файловой системе, используя зарезервированный
каталог подсистемы контроля /tcb/audittmp. Такая
установка файлов конфигурации контроля делается по умолчанию.
Маска событий контроля
Как уже говорилось в разделе "Типы событий контроля", имеется
некоторое число событий контроля, которые можно выбрать:
Таблица 5.5
События контроля
---------------------------------------------------------------------------
A. Startup/Shutdown B. Login/Logoff
C. Process Create/Delete D. Make Object Available
E. Map Object to Subject F. Object Modification
G. Make Object Unavailable H. Object Creation
I. Object Deletion J. DAC Changes
K. DAC Denials L. Admin/Operator Actions
M. Insufficient Privilege N. Resource Denials
O. IPC
...Закладка в соц.сетях
