тема нуждается в защите от несанкционированного доступа к компьютеру дискам и системным файлам.
PAGE 1
Лекция 10
ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ СИСТЕМЫ
Каждая компьютерная система нуждается в защите от несанкционированного доступа к компьютеру, дискам и системным файлам. Средства обеспечения безопасности, имеющиеся в вашей системе, представляют собой расширение базовых средств обеспечения безопасности операционных систем UNIX. Операционная система спроектирована таким образом, чтобы удовлетворять требованиям класса надежности C2, согласно "Критерию оценки надежности компьютерных систем" Министерства обороны (так называемая "Оранжевая книга").
В данной главе показано, как пользоваться средствами обеспечения безопасности для поддержания надежности системы. Средства, касающиеся обычного пользователя, описаны в главе "Использование надежной системы" в "Руководстве пользователя" (User's Guide).
Данная глава содержит следующую информацию:
* общий обзор безопасности системы
* описание защищенных подсистем
* как назначать административные роли
* административное управление подсистемами с помощью sysadmsh
* использование подсистемы контроля
* защита файловых систем
* проверка целостности системы
* сообщения об ошибках
* работа демонов в защищенной системе
* включение защиты с помощью кодового пароля
* как пользователи могут монтировать файловые системы
* как пользователи могут планировать задания
Замечание
О физической секретности
Средства обеспечения безопасности в операционной системе будут бесполезны, если аппаратная часть и носители не защищены. Вы должны защитить от несанкционированного доступа сам компьютер, дистрибутивные дискеты и все носители с резервными копиями. Для этого нужно соблюсти следующие правила:
1. В отсутствие оператора держите систему "под замком".
2. Соберите и заприте все носители с резервными копиями.
ЧТО ТАКОЕ НАДЕЖНАЯ СИСТЕМА?
Поскольку не существует компьютерной системы, в которой риск сведен к нулю, для систем употребляется термин "надежная" (trusted) вместо "безопасная" (secure). Здесь имеется в виду то, что понимается под классом надежности С2. "Надежная" система - это система, в которой достигается некоторый уровень контроля над доступом к информации, обеспечивающий механизмы предотвращения (или по крайней мере фиксирования) несанкционированного доступа.
Средства секретности операционной системы являются расширением средств, имеющихся в типичных, менее "надежных" системах UNIX. Наряду с расширением возможностей защиты пользовательской и системной информации, обеспечивается полная совместимость с существующими механизмами UNIX. Большая часть работы администратора системы включает сопровождение и защиту системной информации, как описано в настоящем разделе.
При установке системы, если включен контроль, система конфигурируется для работы в "надежном" состоянии. В этом состоянии только назначенный администратор может обращаться к системной информации и изменять ее. Как только система переходит в нормальный режим работы, надежное состояние системы следует поддерживать, если вы намерены полностью использовать средства надежности. Если вы будете следовать приведенным рекомендациям, системная информация останется защищенной.
Имеется также возможность приспособить эти требования к нуждам вашей вычислительной установки. Можно даже установить конфигурацию вашей системы таким образом, чтобы она работала в ненадежном режиме, совместимом с другими системами UNIX. Это описано в разделе "Конфигурация для ведения учета, устанавливаемая по умолчанию". Заметим, что если вы решили смягчить требования, определяющие надежное состояние своей системы, ее нельзя с достоверностью восстановить на уровень С2.
Ваши действия как администратора являются решающими для сопровождения надежной системы. Любые упущения в секретном состоянии чреваты проникновением в систему. Чтобы эффективно вести административную работу, вы должны понимать, в чем состоит системная стратегия секретности, как она контролируется системной информацией (базами данных) и как вносимые вами изменения влияют на действия пользователя и администратора.
Концепции надежной системы
Ниже приводятся основные понятия, связанные с надежной системой. Будучи администратором, вы для успешной работы системы должны усвоить эти понятия и знать, где хранится информация, связанная с секретностью. Настоящий раздел является вводным в эту тему; в последующих разделах данной главы приводятся подробности, а также процедуры сопровождения.
Возможность учета
Говорят, что некоторое действие поддается учету, если его можно отследить вплоть до источника - реального пользователя. В безопасной системе все пользователи несут ответственность за свои действия, и каждое действие можно отследить до пользователя, ответственного за него. В большинстве систем UNIX отсутствует хорошая учитываемость: некоторые действия нельзя отследить ни до какого пользователя. Например, псевдо-пользовательские бюджеты, такие как lp или cron, выполняются анонимно; их действия можно обнаружить только по изменениям в системной информации. Как будет описано ниже, надежная система UNIX повышает учитываемость за счет сопоставления каждому бюджету реального пользователя, контроля над каждым действием и сопоставления каждого действия конкретному пользователю в системе.
В типичной системе UNIX у каждого процесса есть реальный и эффективный идентификаторы пользователя, равно как и реальный и эффективный идентификаторы группы. Процесс с эффективным идентификатором пользователя root может устанавливать эти идентификаторы для любых пользователей. Концепция идентификации пользователя расширена включением дополнительного идентификатора, называемого регистрационным идентификатором пользователя (LUID). Это нечто вроде нестираемой метки, проставляемой на каждом процессе, связанном с пользователем. LUID идентифицирует пользователя, ответственного за сессию процесса. LUID процесса, будучи однажды проставлен, не может быть изменен никем. Дочерние процессы наследуют родительский LUID.
Дискреционное управление доступом
Средства дискреционного управления доступом позволяют определить, имеет ли некоторый пользователь доступ к информации, которую он хочет получить. Эта информация находится внутри некоторого объекта (файла, устройства и т.д.), которым пользовательский процесс пытается воспользоваться. В большинстве систем UNIX защита объекта осуществляется через взаимосвязь между пользователем и группой процесса, с одной стороны, и битами режимов объекта (владелец, группа, прочие), с другой стороны. Атрибуты защиты для этих объектов находятся на усмотрении владельца объекта. Поэтому эти атрибуты владелец может сделать ограничивающими (контролируемый доступ) или разрешающими (открытый доступ). В надежной системе UNIX стандартные правила дискреционного управления доступом расширены так, что они обеспечивают более полную защиту системной информации (системных баз данных), разделяемой информации (временных каталогов) и входных файлов программы SUID (установка идентификатора пользователя при выполнении) - например, сообщения почты.
Помимо этого, в дискреционную стратегию доступа для UNIX добавлен механизм, который может воспрепятствовать получению программой SUID доступа к файлам запустившего ее пользователя. Пользователь может создать промен (promain - protected domain, т.е. защищенный домен). Промен является иерархией каталогов (поддеревом). Когда пользователь запускает программу SUID, она может произвести доступ к своим личным файлам только в том случае, если эти файлы находятся в упомянутом поддереве. Вне промена программа SUID имеет доступ только к тем файлам, к которым имеют доступ и активизатор программы, и ее владелец. Это сужает рамки разрушения, которое может быть вызвано программой SUID в данном каталоге. Такой механизм подробно описывается в странице Руководства для promain(M) в "Справочнике пользователя" (User's Reference).
Авторизации
Авторизация - это право на доступ к некоторому объекту или на выполнение какого-либо системного действия. В большинстве систем UNIX все решения по поводу доступа принимаются на основе простых дискреционных критериев, или исходя из того, является ли root владельцем процесса, осуществляющего доступ. Корневой бюджет имеет полномочия на выполнение таких системных действий, какие не может выполнять никакой другой процесс. Операционная Система определяет два типа авторизаций: авторизации ядра и авторизации подсистемы. Авторизации ядра связаны с процессами.
(Процесс - это программа, выполняющаяся в системе в данный момент.) Они разрешают процессу выполнять определенные действия, если процесс наделен требуемыми привилегиями. Авторизации подсистемы связаны с пользователями. Они позволяют пользователю выполнять специальные действия с помощью команд подсистемы (надежные утилиты и программы). Подсистема - это связный набор файлов, устройств и команд, служащих для выполнения некоторой функции. Например, подсистема lp состоит из файлов блока подкачки печати, печатающих устройств и команд, помогающих сопровождать подсистему, таких как lpadmin(ADM).
Авторизации ядра хранятся в авторизационном наборе, который сопоставляется каждому процессу. Авторизационный набор - это список привилегий, который разрешает некоторый тип действий при наличии определенной привилегии и запрещает в ее отсутствие. Авторизации будут рассмотрены позже.
Установление идентичности и аутентичности (I&A)
Когда пользователь регистрируется в малонадежной системе UNIX, выполняется ограниченная процедура установления идентичности и аутентичности. Система ищет имя пользователя в базе данных паролей (/etc/passwd). Если имя пользователя отыскивается, система устанавливает аутентичность пользователя, сравнивая введенный пароль с шифрованной версией пароля, содержащейся в строке базы данных паролей пользователя. Предусмотрены некоторые правила относительно характеристик пароля и возможности его изменения, но, как показала практика, этих правил недостаточно для предохранения от проникновения через защиту.
Надежная система расширяет стандартные механизмы I&A. В ней предусмотрено больше правил, касающихся типов используемых паролей. Имеются процедуры генерации и изменения паролей. Изменены местоположение и механизм защиты некоторых частей базы данных паролей. И, наконец, администратор теперь обладает большими возможностями контроля над действиями пользователей. Для обеспечения этого аспекта системы создана специальная роль - Администратор аутентификации (авторизация подсистемы auth). Обязанности этого администратора подробно описываются в последующих разделах.
.
Контроль (audit)
В большинстве систем UNIX ведется ограниченная регистрация системных действий с помощью соответствующей учетной подсистемы. Учетная подсистема пишет одну учетную запись при завершении каждого пользовательского процесса. Надежная операционная система обеспечивает продолжительный ряд записей о действиях – журнал (trail). В этот журнал заносится запись о каждом доступе, осуществляемом между субъектом и объектом, и о каждом изменении субъекта, объекта и системных характеристик. Подсистема контроля управляется специальной ролью, называемой Администратором контроля (авторизация подсистемы audit). Администратор контроля решает, сколько информации следует записать и насколько надежно она записывается, а также сопровождает информацию, когда она собрана. Подсистема контроля предоставляет Администратору контроля обширную историю системных действий. Это помогает администратору идентифицировать, что произошло в системе, когда и с чьим участием.
Защищенные подсистемы
В системах UNIX существуют механизмы setuid - установка идентификатора пользователя (SUID) - и setgid - установка идентификатора группы (SGID). С их помощью можно составлять программы, обеспечивающие личную информацию. Доступ к этой информации и ее изменение разрешены только операциям, включенным в данные программы. Операционная Система определяет несколько защищенных подсистем. Каждая из таких подсистем состоит из совокупности личной информации (файлы и/или базы данных), любых связанных с ними устройств, а также утилит и команд, используемых для сопровождения этой информации. Защищенные подсистемы пользуются механизмами SUID/SGID для защиты своих личных файлов, баз данных и устройств от неограниченного доступа. Операционная Система расширяет понятие защищенной подсистемы в нескольких аспектах:
* в ней определена большая грануляция пользователей и групп, обеспечивающих определенные наборы системных ресурсов (личная информация);
* она ведет специальную базу данных для пользователей, которым разрешено выполнять программы, сопровождающие личную информацию;
* в ней не требуется, чтобы пользователи регистрировались в качестве администратора подсистемы; вместо этого используется база данных для проверки авторизации подсистемы. Этого достаточно для удовлетворения всех требований относительно полной учитываемости любых действий, выполняемых программами подсистемы.
РАБОТА НАДЕЖНОЙ СИСТЕМЫ
В данном разделе обсуждается концептуальная структура сопровождения надежной системы. Первое основное решение, которое вы должны принять, - кто будет ее сопровождать. Вы можете иметь одного всемогущего супер-пользователя, зарегистрированного как root, или можно распределить административные обязанности между другими пользователями, выделяя им ровно столько возможностей, сколько необходимо для административного управления каким-либо одним аспектом работы системы.
Назначение административных ролей с помощью авторизаций
В надежной системе UNIX административные задачи распадаются на несколько логических ролей. Каждая роль ответственна за сопровождение одного аспекта системы. Идея о специфических административных ролях (и соответствующих им задачах и обязанностях) является кардинальной в вашем представлении о надежной операционной системе. Любая логическая роль может быть назначена одному и тому же пользователю или различным членам некоторой административной группы. С каждой расширенной ролью связана специальная авторизация. Эта связь, наряду со сложной системой трассировки, позволяет администратору вести полную регистрацию административных действий. Это помогает предотвращать одни проблемы и облегчать идентификацию и устранение других проблем.
Для выполнения задач, связанных с административной ролью, администратор должен иметь соответствующую авторизацию. В приводимой ниже таблице перечисляются административные роли, связанные с ними авторизации, а также разделы системы, сопровождаемые каждой ролью.
Таблица 5.1 Защищенные подсистемы и административные роли
---------------------------------------------------------------------------
Роль | Авторизация | Раздел системы | подсистемы |
---------------------------------------------------------------------------
Администратор | auth | Системный учет аутентификации | |
Администратор принтера | lp | Подсистема устройства | |
построчной печати
Администратор терминала* | terminal | Разрешения для терми- | |
нального устройства
Администратор cron * | cron | Подсистема at и cron
Администратор памяти * | mem | Доступ к памяти системы
Администратор контроля | audit | Базы данных контроля и | |
контрольный журнал
Оператор | backup | Резервные копии файловой | |
системы
Администратор системы | su | Доступ su к бюджету | |
супер-пользователя
| sysadmin | Использование программы | |
integrity(ADM)
---------------------------------------------------------------------------
* В действительности эти роли не совсем административные, как поясняется ниже.
Вы обязательно должны понять, какие обязанности включает в себя каждая роль, и как ваши действия повлияют на секретность системы. При формировании конфигурации и работе системы вы должны исходить из чувствительности информации, хранящейся на вашей вычислительной установке, осознания степени взаимодействия и компетенции ваших пользователей, и угрозы (извне или изнутри) проникновения через защиту или неправильной работы. Лишь ваша бдительность и корректное использование системы смогут сохранить ее надежность и защитить ее целостность. Для назначения авторизации подсистемы необходимо в sysadmsh сделать следующий выбор:
Accounts -> User -> Examine:Privilege
Замечание
Вы, вероятно, заметили, что каждая авторизация подсистемы оказывается идентичной групповому имени этой подсистемы. Это означает, что если какой-то пользователь является членом группы подсистемы, то тем самым он имеет доступ к файлам подсистемы. Тем не менее, это не дает требуемой авторизации подсистемы. На самом деле никогда не следует делать пользователя членом группы подсистемы, так как это подвергнет риску актуальные файлы данных. Для разрешения доступа к подсистеме используйте соответствующую авторизацию подсистемы.
Административное управление подсистемами с помощью sysadmsh
Некоторые подсистемы являются логическими разделами, а не действительными областями администрации системы. Например, подсистема памяти по существу не подлежит административному управлению, но присваивание авторизации mem обеспечит контроль над доступом к структурам памяти ядра. Другие подсистемы нуждаются в администрации, и каждой из них соответствует определенный выбор в sysadmsh(ADM). Такие подсистемы могут быть назначены отдельным людям; по каждой области имеется документация. В таблице 5.2 приведен список административно управляемых подсистем, соответствующие им выборы sysadmsh и разделы или главы, в которых они рассматриваются.
Таблица 5.2
Подсистемы и выборы sysadmsh
--------------------------------------------------------------------------------------------------------------------------------
Защищенная | Выбор | Раздел или глава подсистема | sysadmsh |
----------------------------------------------------------------------------------------------------------------------------------------------
Устройство постро - | Printers | "Использование принтеров" чной печати | |
Дублирование | Backups | "Дублирование файловых систем"
Аутентификация | Accounts | "Административное управление | |
пользовательскими бюджетами"
Cron | Jobs | "Авторизация использования | |
команд планирования заданий" | (в данной главе)
Контроль | System->Audit | "Использование подсистемы | |
контроля" (в данной главе)
Подсистема audit описана ниже в данной главе. Подробное описание подсистем содержится в "Справочнике пользователя" (User's Reference), на странице, относящейся к subsystem(M). Там приведен список всех программ и файлов данных, связанных с каждой подсистемой. Большинство функциональных возможностей, обычно доступных супер-пользователю в других, менее надежных системах UNIX, переданы защищенным подсистемам, описываемым в данном разделе. Однако некоторые функции все равно должен выполнять суперпользователь. К их числу относятся монтирование и демонтирование файловых систем, прохождение по полному дереву файла. Только супер-пользователь может делать все. Пользователи, обладающие авторизацией su, имеют доступ su(C) к бюджету супер-пользователя. Следует ограничить число пользователей, имеющих доступ к паролю root, и назначить ответственного пользователя для бюджета root. (Подробности см. в главе "Административное управление пользовательскими бюджетами" в настоящем руководстве.)
Назначение авторизаций ядра
В операционной системе имеется два типа авторизаций: для ядра и для подсистемы. Пользовательские процессы выполняются с набором авторизаций ядра, которые контролируют специальные права процесса на некоторые привилегированные системные действия. В Таблице 5.3 приведен список авторизаций ядра.
Таблица 5.3 Авторизации ядра
---------------------------------------------------------------------------
Авторизация | Действие
---------------------------------------------------------------------------
configaudit | Модификация параметров контроля
writeaudit | Внесение контрольных записей в контрольный журнал
execsuid | Выполнение программ SUID
chmodsugid | Возможность устанавливать бит SUID и SGID в файлах
chown | Смена владельца объекта
suspendaudit | Приостанов контроля процесса
nopromain | Доступ пользователя извне каталога промена
Большинству пользователей требуются только авторизации nopromain и execsuid для выполнения стандартных задач. (Промены используются для изолирования выполнения данной программы, а не как постоянная мера защиты. nopromain - это обычный режим, с которым работает пользователь; он его временно отменяет для проверки выполнения программы. Подробнее см. promain(M).) Чтобы выполнять программы SUID, пользователь должен иметь авторизацию execsuid. (Программы установки идентификатора пользователя выполняются под контролем идентификатора, отличного от идентификатора инициатора этих программ. Так сделано для того, чтобы процесс имел доступ к файлам и системным средствам, которые в противном случае были бы недоступны.) Если пользователю нужно создавать файлы с битами SUID или SGID, он должен иметь авторизацию chmodsugid. Чтобы сменить владельца файла (отдать файл), нужна авторизация chown. Если у пользователя нет этой авторизации, владельца файла может изменить только root.
Замечание
Для соответствия NIST FIPS 151-1 необходимо ограничение на chown. Эту авторизацию не нужно выдавать пользователям, если вы намерены соблюдать требования NIST FIPS 151-1.
У каждого процесса имеется набор авторизаций, в котором перечислены его авторизации ядра. Процесс может выполнить некоторое действие, только если соответствующая авторизация ядра входит в набор. Например, процесс с авторизацией configaudit может модифицировать параметры подсистемы контроля. Такой процесс выполняется Администратором контроля. Не следует выполнять никакие пользовательские процессы с какой-либо из авторизаций audit. Они предназначены для исключительного использования Администратором контроля. Для назначения авторизации ядра нужно сделать в sysadmsh следующий выбор:
Account->User->Examine:Privileges
Пользователи, которым присвоены административные роли, должны иметь определенные авторизации ядра, чтобы выполнять задачи, требуемые подсистемой. Если вы используете общесистемные авторизации ядра, принимаемые по умолчанию ("C2" или "Relaxed"), вам придется назначить лишь обязательные авторизации контроля; авторизации chown, execsuid и chown уже назначены.
Таблица 5.4 Требования подсистем относительно авторизаций ядра
---------------------------------------------------------------------------
Подсистема | Требуемые авторизации ядра
---------------------------------------------------------------------------
audit | configaudit, suspendaudit, execsuid
auth | chown, execsuid
backup | execsuid
lp | chown
cron | execsuid, chown, chmodsugid
sysadmin | execsuid, chmodsugid, chown
Использование параметров секретности, настроенных или принятых по умолчанию
По умолчанию параметры секретности устанавливаются согласно уровню надежности С2. Как упоминалось выше, существует два доступных набора параметров, принимаемых по умолчанию: C2 и "Relaxed", соответствующий характеру работы менее надежных систем UNIX. Кроме того, можно изменить любой параметр - и для отдельных пользователей, и по всей системе. Изменение общесистемных параметров описано в разделе "Конфигурация для ведения учета, устанавливаемая по умолчанию" в главе "Административное управление пользовательскими бюджетами". Информация о параметрах для отдельных пользователей приведена в разделе "Управление учетом" той же главы.
Управление системным доступом
Одним из важных аспектов работы в надежной системе является выявление потенциальных проблем, относящихся к секретности. Ограничительные механизмы подразделяются на три категории, каждая из которых может быть приспособлена к конкретным требованиям и сопровождаться отчетами:
* Статус пароля
* Активность терминала
* Активность начальной регистрации
Каждая из этих областей имеет важное значение для точного определения потенциальных проблем с секретностью. Процедуры для выполнения этих отчетов можно найти в разделе "Генерация отчетов об активности" в главе "Административное управление пользовательскими бюджетами". В последующих подразделах поясняется, как реализуются эти ограничения.
Статус пароля
В качестве модели для введения ограничений на пароли был использован документ "Руководство по использованию паролей" (Password Management Guideline) Министерства обороны; поэтому пользователи подвергаются более серьезной проверке на пароли, чем в менее надежных системах UNIX. Администратор аутентификации может либо разрешить пользователям самим выбирать себе пароли, либо обязать систему генерировать для них пароли. Пароль, будучи однажды выбран, может подвергнуться большому числу элементарных проверок, что опять же зависит от Администратора аутентификации.
Для паролей существует три уровня действительности, что является расширением реализации процесса старения пароля в стандартной системе UNIX. Пароли остаются действительными, пока не настанет достигнут его срок истечения действия. Когда срок действия пароля истекает, пользователь (если ему разрешено это делать) получает приглашение на изменение своего пароля. Если пользователю не разрешено менять свой пароль, администратор должен назначить новый пароль.
Пароли считаются expired, пока не завершится их жизненный цикл. Мертвый пароль вызывает блокирование пользовательского бюджета. Снять эту блокировку может только Администратор аутентификации, используя выбор Accounts в sysadmsh. Если пользователю не разрешено менять пароль, нужно назначить новый.
Во избежание повторного использования паролей Администратор аутентификации может также установить минимальный срок изменения для пароля, до которого пользователь не имеет права менять пароли. Все эти параметры можно изменить - и по всей системе (база данных системных параметров, принимаемых по умолчанию), и для отдельных пользователей (база данных защищенных паролей). Общесистемное изменение параметров паролей описано в разделе "Изменение ограничений на пароли, принятых по умолчанию" в главе "Административное управление пользовательскими бюджетами" настоящего руководства, а полное описание процедур изменения паролей приведено в разделе "Изменение пароля пользователя или параметров пароля" той же главы.
Отчеты по паролям можно использовать для предотвращения блокировки пользовательских бюджетов; эта ситуация очень неприятна, если администратор системы отсутствует. Если в вашей системе не принято ежедневное присутствие администраторов, вы имеете право претендовать на соответствующее увеличение параметра жизненного цикла пароля.
Активность терминала
Терминал - это вход в вашу систему. Помимо использования паролей бюджетов, терминалы можно защитить от попыток проникновения в систему. Можно задать максимальное число неудачных попыток регистрации, которые обычно связаны с попытками угадать пароль бюджета. Терминалы, для которых превышено максимально допустимое число попыток, будут заблокированы; снимать блокировку должен Администратор бюджетов. Кроме того, можно задать интервал времени, который должен пройти между попытками регистрации, что также может помочь пресечь попытки угадать пароль. (Аналогичные ограничения можно ввести для бюджетов, отличных от терминалов.) О том, как изменять или проверять ограничения для терминала, см. раздел "Управление регистрацией терминала" в главе "Административное управление пользовательскими бюджетами" настоящего руководства.
Активность начальной регистрации
Как и в случае терминалов, у пользовательских бюджетов есть параметры, связанные с числом попыток регистрации и интервалом для повторной попытки, которые относятся к регистрации в бюджете, а не в терминале. О том, как изменять или проверять эти ограничения, см. раздел "Изменение ограничений при регистрации, принятых по умолчанию" в главе "Административное управление пользовательскими бюджетами" настоящего руководства.
.
ИСПОЛЬЗОВАНИЕ ПОДСИСТЕМЫ КОНТРОЛЯ
Подсистема контроля регистрирует события в системе, связанные с секретностью, записывая их в контрольный журнал, который затем можно просмотреть. В контрольных журналах, выдаваемых подсистемой, можно фиксировать проникновение в систему и неправильное использование ресурсов. Подсистема контроля спроектирована в соответствии с задачами контроля, определяемыми Национальным центром защиты данных компьютеров США.
Контроль позволяет просматривать собранные данные для изучения образцов доступа к объектам и наблюдения за действиями отдельных пользователей и их процессов. Попытки нарушения защиты и механизмов авторизации контролируются. Подсистема контроля дает высокую степень гарантии обнаружения попыток обойти механизмы обеспечения безопасности. Поскольку события, связанные с секретностью, контролируются и поддаются учету вплоть до выявления конкретного пользователя, подсистема контроля служит сдерживающим средством для пользователей, пытающихся неправильно воспользоваться системой.
Подсистема контроля использует системные вызовы и утилиты для классификации действий пользователей, подразделяя их на типы событий. Это можно использовать для выборочной генерации и редукции контроля. Один из этих типов событий, Отказ дискреционного доступа (DAC), регистрирует попытки такого использования объектов, которое не допускается разрешениями для этого объекта. Например, если пользовательский процесс пытается писать в файл "только для чтения", регистрируется событие Отказа DAC, показывающее, что процесс пытался произвести запись в файл, на что у него не было права. Если просмотреть контрольный журнал, то легко будет заметить повторяющиеся попытки доступа к файлам, на которые не выданы разрешения.
Для эффективности данных контроля существенна возможность учета пользователей, выполняющих действия, подлежащие контролю. Когда пользователи пытаются войти в систему, они должны пройти процесс идентификации и аутентификации, прежде чем им будет предоставлен доступ в систему. Механизм секретности снабжает каждый процесс, создаваемый пользователем, постоянным индикатором идентичности - регистрационным идентификатором пользователя (LUID).
Этот идентификатор сохраняется невзирая на переходы от одного пользовательского бюджета к другому с помощью таких команд, как su(C). Каждая контрольная запись, генерируемая подсистемой, содержит LUID наряду с эффективным и реальным идентификаторами пользователя и группы для процесса. В итоге оказывается возможным строгий учет действий пользователей.
Подсистема контроля управляется Администратором контроля. Будучи Администратором контроля, вы обладаете полным контролем над событиями, выбранными для генерации контрольных записей, над значениями параметров подсистемы контроля и над последующей редукцией и анализом данных контроля.
Компоненты подсистемы контроля
Подсистема контроля состоит из четырех главных компонентов:
* Механизм контроля ядра
* Драйвер устройства контроля (/dev/audit)
* Демон уплотнения данных контроля - auditd(ADM)
* Интерфейс контроля sysadmsh
Существует несколько надежных системных утилит, которые, хотя на самом деле и не являются собственно частью подсистемы контроля, отвечают за занесение контрольных записей в контрольный журнал (например, login(M)).
Механизм контроля ядра
Механизм контроля ядра является центральным в подсистеме контроля. Этот механизм генерирует контрольные записи, исходя из активности пользовательских процессов, с помощью системных вызовов ядра. Каждый системный вызов ядра содержит строку в таблице подсистемы, где указано, связан ли этот вызов с вопросами секретности, и если это так, то какому типу события он соответствует. Кроме того, используется таблица кодов ошибок, позволяющая классифицировать системные вызовы на конкретные события, связанные с секретностью. Механизм контроля ядра выдает внутренний вызов в драйвер устройства для занесения записи в контрольный журнал.
Например, системный вызов open(S) классифицируется как событие Сделать объект доступным. Если пользователь blf выполняет open(S) для /unix и делает это успешно, генерируется контрольная запись об этом событии. Однако если системный вызов заканчивается неудачно из-за того, что blf запросил в open(S) доступ по записи, не имея разрешения на запись в этот файл, это действие классифицируется как событие Отказ дискреционного доступа для blf и объекта /unix. Следовательно, системный вызов можно отобразить в несколько типов событий, в зависимости от объекта, к которому осуществляется доступ, и/или результата вызова. Поэтому возникает возможность выборочного контроля системных вызовов, в зависимости от типов событий, которые вы сделаете доступными.
Некоторые системные вызовы не относятся к секретности. Например, getpid(S) получает идентификатор процесса и не определяет событие, связанное с секретностью. Таким образом, этот системный вызов не подлежит контролю.
Драйвер устройства контроля
Драйвер устройства контроля выполняет следующие функции:
прием контрольных записей от механизма контроля ядра и от надежных утилит; создание и запись промежуточных файлов контрольного журнала; предоставление данных контрольного журнала демону контроля для уплотнения; обеспечение выборочной генерации контрольных записей на основе типов событий, идентификаторов пользователей и идентификаторов групп.
Драйвер устройства обеспечивает интерфейсы open(S), close(S), read(S), write(S) и ioctl(S), как и прочие символьные устройства. Однако устройство контроля может быть открыто только процессами, обладающими авторизациями ядра configaudit и/или writeaudit. Это ограничивает доступ к устройству контроля, разрешая его только для надежных утилит, таких как интерфейсы демона контроля и Администратора контроля. В устройство контроля могут писать несколько процессов одновременно. Это устройство производит объединение записей в контрольный журнал. Читать с устройства может только один процесс - демон контроля.
Драйвер устройства контроля ведет контрольный журнал в виде набора файлов сбора данных контроля. Каждый раз, когда вы включаете контроль, начинается новая сессия контроля. При ее запуске подсистема создает файл сбора данных, в который заносятся контрольные записи. Когда файл сбора данных достигает определенного размера, установленного администратором, подсистема создает новый файл сбора данных и начинает писать в него. Поэтому контрольный журнал можно рассматривать как постоянно увеличивающийся последовательный файл, даже если используется несколько файлов сбора данных. Именно в таком виде контрольный журнал рассматривается демоном контроля, потому что он читает с устройства и получает записи из контрольного журнала. При достижении конца файла сбора данных подсистема выполняет соответствующее переключение на новый файл сбора данных. Все это прозрачно для демона.
Демон контроля
Демон контроля auditd(ADM) - это надежная утилита, выполняющаяся как фоновый демон-процесс при включении контроля. Этот демон - единственный, кто читает с устройства контроля, которое в свою очередь представляет демону блоки записей из файлов сбора данных контроля. Демону безразлично, что контрольный журнал расслаивается на множество файлов сбора данных. Драйвер устройства контроля удовлетворяет запросы на чтение, поступающие от демона, и обрабатывает переключение и удаление файлов сбора данных по мере надобности.
Главное предназначение демона состоит в предоставлении механизма уплотнения данных и регистрации для сессии контроля. Демон также выполняет функцию поддержки защищенных подсистем, позволяя им писать в подсистему контрольные записи. В зависимости от выбранного вами критерия формирования контрольных записей, в системе может быть сгенерировано огромное количество данных контроля. В типичном случае однопользовательской системы генерация 200 килобайтов данных контроля за час не будет выглядеть необычно. Поэтому демон предоставляет механизм уплотнения для сжатия данных контроля в упакованный формат записи, которая сохраняется в файле уплотнения контроля.
Второй функцией демона является обеспечение журнального файла, описывающего текущую сессию контроля. Журнальный файл содержит информацию о количестве контрольных записей, доступных в уплотненных файлах вывода в сессии; время запуска и останова сессии; а также другие индикаторы состояния сессии контроля. Как только драйвер устройства контроля переключает файлы сбора данных при достижении ими размеров, установленных администратором, демон может создать несколько уплотненных файлов, чтобы не допустить увеличения одного файла до размеров, недоступных управлению. Вы также это контролируете. Кроме того, уплотненные файлы, записанные демоном, можно разместить в любом каталоге, определенном администратором. По этим причинам ведется журнальный файл - чтобы иметь журнал с уплотненными файлами, которые можно использовать для последующей редукции данных.
Третья функция демона контроля - выполнять роль программы интерфейса с драйвером устройства контроля для занесения контрольных записей из защищенных подсистем, не имеющих авторизации writeaudit. Так как эти подсистемы не могут осуществлять доступ непосредственно к драйверу устройства контроля, но могут образовать интерфейс с демоном с соблюдением секретности, то демон выполняет занесение контрольной записи прикладной программы в подсистему.
Средство редукции/анализа данных
sysadmsh также включает в себя утилиту редукции/анализа данных, которая облегчает исследование контрольных журналов предыдущих сессий контроля или текущей сессии контроля. Используя журнальный файл, созданный демоном контроля, утилита редукции может идентифицировать все уплотненные файлы, нужные для редукции сессии контроля. Так как уплотненные файлы имеют сжатый формат, программа редукции содержит подпрограммы, необходимые для развертывания файлов.
Для обеспечения эффективного анализа данных контроля утилита редукции позволяет задавать для выборочной редукции данных определенные типы событий, идентификаторы пользователей, идентификаторы групп и имена объектов. Более того, вы можете задать интервал времени, в течение которого должен производиться поиск записей, удовлетворяющих выбранному критерию. Если какая-либо запись не попадает в этот интервал, она отбрасывается в данной редукции.
Например, вы можете выполнять редукцию данных, выбирая событие Отказа DAC для пользователя с идентификатором blf, ведущего поиск объекта /unix. Будут распечатаны только те записи, которые отражают попытки доступа blf к /unix, отвергнутые ввиду отсутствия нужных разрешений. Это образует мощный механизм для идентификации событий секретности, представляющих актуальный интерес, без анализа всего контрольного журнала.
Методология контроля
В данном разделе описывается, как функционирует подсистема контроля, какие критерии используются при сборе данных, и как требования контроля влияют на производительность системы.
Авторизации контроля
С подсистемой контроля связаны три авторизации:
configaudit, writeaudit и suspendaudit.
Авторизация configaudit позволяет устанавливать параметры контроля для всех пользователей системы.
Авторизация writeaudit позволяет регистрировать специфическую информацию в контрольном журнале.
Авторизация suspendaudit отключает всякий контроль.
Источники контрольных записей
Контрольный журнал содержит содержит информацию о событиях в системе, связанных с секретностью. Эффективный контроль охватывает не только запросы на системные вызовы, поступающие от пользовательских процессов, но и определенные события, такие, как вход в систему, выход из системы, неудачные попытки регистрации. Эти события критичны для определения того, кто выполнял доступ к системе, в какие моменты времени, с какого терминала, и какие именно действия были выполнены. Неудачные попытки регистрации невозможно контролировать на уровне ядра, поскольку ему неизвестно, что конкретно делает прикладная программа. Таким образом, следует дать возможность генерировать контрольные записи и некоторым утилитам, влияющих на секретность, например login.
Контрольные записи генерируются из трех источников (описываемых в последующих разделах):
* механизм контроля ядра
* надежные прикладные процессы
* авторизованные подсистемы
Механизм контроля ядра
Значительная часть контрольных записей, хранящихся в контрольном журнале, генерируется механизмом контроля ядра. Этот раздел подсистемы контроля генерирует записи в ответ на системные вызовы пользовательских процессов, отображаемые в события, связанные с секретностью. Некоторые системные вызовы, например open(S), отображаются в несколько событий секретности, в зависимости от аргументов пользователя и от состояния открываемого файла. Если open(S) вызывается с флагом O_CREAT, файл создается, если он не существовал. Если задан флаг O_TRUNC, выполняется усечение файла до нулевой длины, если он существует. Это показывает, как вызов open(S) может отобразиться в одно из трех различных событий: Сделать объект доступным, Создание объекта или Модификация объекта.
Важную роль в определении события играют также коды ошибок. Ошибки при выполнении системных вызовов, указывающие, что доступ или разрешение отвергнуты, равно как и проблемы потребления ресурсов, отображаются в конкретные типы событий. Механизм контроля ядра в конце системного вызова определяет, какому классу событий принадлежит вызов, и задали ли вы контроль этого события. Более того, данный механизм может также применить дополнительные критерии выбора, например, идентификатор пользователя или идентификатор группы. Таким образом можно ограничить генерацию контрольных записей, задав ее только для избранной группы пользователей.
Надежные прикладные программы
Надежная вычислительная база (TCB) содержит несколько надежных прикладных программ, необходимых для обеспечения безопасной среды. Среди них - login, su и различные команды подсистемы контроля. Для сокращения объема данных контроля, записанных в контрольный журнал, и для повышения значимости информации в журнале этим надежным прикладным программам разрешено писать прямо на устройство контроля. Тем самым, например, login сможет занести контрольную запись о регистрации в системе прямо в контрольный журнал, вместо того, чтобы представлять эту регистрацию в виде набора системных вызовов, требуемых для завершения этой процедуры.
Но недостаточно просто позволить надежным прикладным программам писать на устройство контроля. В механизме контроля ядра должен быть также предусмотрен способ подавления генерации контрольных записей о системных вызовах, чтобы избежать загромождения контрольного журнала. Для этого существует авторизация suspendaudit, о которой уже шла речь. Надежные прикладные программы выполняются с этой авторизацией, что позволяет приостановить контроль системных вызовов ядра для данного процесса и разрешить ему открывать устройство контроля и писать в него. Только нескольким надежным прикладным программам разрешено это делать. Обычный пользовательский процесс никогда не выполняется с авторизацией suspendaudit. Механизмом авторизации управляет login, используя ограниченные системные вызовы; этот механизм использует элементы базы данных защищенных паролей.
Авторизованные подсистемы
Третий способ генерации контрольных записей использует авторизованные подсистемы, такие, как lp, cron, terminal и mem. Иногда подсистема наталкивается на аномалии или проблемы, для которых желательно составить информативную контрольную запись. Однако подсистемы не имеют авторизации writeaudit и не могут заносить контрольные записи непосредственно в подсистему.
Вместо этого подсистемы формируют записи, как надежные прикладные программы, и представляют их процессу демона контроля через защищенный интерфейс. Демон контроля, являющийся надежной прикладной программой, записывает контрольную запись в устройство контроля. Это позволяет процессам защищенных подсистем генерировать осмысленные и информативные контрольные записи, не по-
лучая авторизации 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).
Обязательный контроль не ограничивается только этой группой системных вызовов. Событие регистрации является единственной обязательной контрольной записью для надежных прикладных программ. Когда пользователь регистрируется в системе, в регистрационную запись заносится индикатор терминала, на котором была выполнена регистрация. Если один и тот же пользователь зарегистрируется на нескольких терминалах в системе, его действия можно отслеживать вплоть до конкретного терминала.
Типы событий контроля
Каждая контрольная запись, независимо от того, чем вызвано ее появление, сопровождается отметкой о типе события. Для системных вызовов пользовательского процесса тип события определяется механизмом контроля ядра, исходя из самого системного вызова и из его результата, как уже говорилось выше. При контроле прикладной программы или подсистемы тип события устанавливает процесс, формирующий контрольную запись. Этот тип события не изменяется ни устройством контроля, ни демоном контроля.
Типы событий имеют важное значение, так как они классифицируют события в системе, связанные с секретностью. И генерацией, и редукцией контрольных записей можно управлять, основываясь на типах событий. Например, если вы интересуетесь только пользователями, входящими в систему и выходящими из нее, можно задать этот тип события для сбора или редукции данных. Заметьте, что если вы запрашиваете выборочный сбор событий, то информация о событиях тех типов, которые вы исключили, не пишется в контрольный журнал и, разумеется, не подлежит последующей редукции.
В подсистеме контроля имеется широкий диапазон типов событий, нарушающих равновесие между грануляцией и соответствующими классами секретности. Поддерживаются следующие типы событий:
* Запуск и останов системы
* Вход в систему и выход из нее
* Создание и прекращение процесса
* Отображение объектов (например, файлов) в субъекты (например, процессы)
* Сделать объект доступным
* Сделать объект недоступным
* Создание объекта
* Модификация объекта
* Удаление объекта
* Связь между процессами
* Изменения дискреционного доступа
* Отказы дискреционного доступа
* Недостаточная авторизация
* Отказы ресурса
* Действия Администратора системы/оператора
* Действия авторизованной подсистемы
* Действия секретной базы данных
* События подсистемы контроля
Вы можете, используя эти типы событий, выполнять выборочный сбор и редукцию данных контроля. Интерфейс подсистемы контроля позволяет составлять список типов событий либо для подсистемы контроля, либо для программы редукции данных.
Подсистема контроля использует типы событий для того, чтобы
определить, нужно ли заносить контрольную запись в контрольный журнал. Будучи Администратором контроля, вы полностью управляете отбором событий для контроля.
Для управления контролем типов событий в подсистеме контроля имеется глобальная системная маска событий контроля, которая описана ниже. Подсистема контроля также обеспечивает маску типов событий для каждого процесса в системе (также описана ниже). Обе эти маски являются битовыми представлениями целочисленных значений типов событий, подлежащих контролю.
Системная маска событий контроля
Системная маска событий является глобальной для подсистемы контроля. Ее можно установить с помощью sysadmsh и изменить в процессе контроля, если возникает необходимость выбрать другой набор событий. В системной маске событий каждому типу события соответствует один бит; он устанавливается равным единице, если контроль нужен. Это позволяет быстро проверять (с помощью битовых операций), подлежит ли контролю только что созданная запись.
Подсистема контроля использует системную маску событий для вычисления пользовательских масок, когда при регистрации в системе создается новый процесс.
Пользовательская маска событий и маска событий процесса
Вы можете отменить действие общесистемной маски событий для любого пользователя, установив пользовательскую маску событий в пользовательской строке защищенного пароля. Каждый процесс в системе обладает маской событий процесса, которая говорит системе, что нужно контролировать для данного процесса. При регистрации пользователя программа login анализирует пользовательскую маску событий и устанавливает маску событий процесса для командного процессора регистрации следующим образом.
В пользовательской маске событий для каждого типа события контроля предусмотрено одно из трех значений:
* всегда контролировать это событие
* никогда не контролировать это событие
* использовать системную маску событий контроля
Для каждого типа события контроля маска контроля процесса устанавливается по пользовательской маске, если в ней указано, что данное событие контролируется всегда или никогда. В противом случае маска контроля процесса устанавливается по системной маске событий контроля. В большинстве случаев в пользовательской маске событий будет установлено третье значение для всех событий контроля, в результате чего для этого пользователя будут применяться системные параметры, принятые по умолчанию. Пользовательскую маску можно использовать для того, чтобы увеличивать или уменьшать контролируемый объем информации о пользователях, которым вы соответственно меньше или больше доверяете по сравнению с остальными.
Эффективный системный контроль
При использовании подсистемы контроля нужно следовать некоторым правилам. Подсистема спроектирована так, чтобы обеспечить гибкую производительность и надежность и дать возможность собирать те данные контроля, какие вы желаете. Генерация контрольной записи поддерживает предварительную выборку событий контроля, идентификаторов пользователей и идентификаторов групп. Предварительная выборка нужна, если вы по каким-то причинам хотите сконцентрироваться на каком-либо конкретном пользователе или группе пользователей (когда отдельные пользователи имеют обычай пытаться обращаться к файлам, к которым им не разрешен доступ). Для предварительной выборки можно также использовать типы событий - например, контроль только событий входа в систему и выхода из нее. Предварительная выборка, кроме того, дает экономию пространства на диске, так как уменьшается число контрольных записей, заносимых подсистемой контроля в файлы сбора данных. Но в ис-
пользовании предварительной выборки есть и отрицательная сторона. Если произошло нарушение секретности системы, и это событие или совершивший его пользователь не был выбран для контроля, то запись об этом действии будет утеряна.
Поэтому следует быть более консервативными - не делать предварительную выборку событий контроля и пользователей/групп, а вместо этого осуществлять полный контроль. В итоге любое происшедшее событие, связанное с секретностью, будет зафиксировано в контрольном журнале. Недостатки полного контроля: он занимает много места на диске и увеличивает накладные расходы в системе.
Вы можете комбинировать полный контроль с пост-выборкой, изучая только записи, представляющие интерес. Пост-выборка обеспечивает выборочный анализ контрольного журнала на основе типов событий, идентификаторов пользователей, идентификаторов групп и имен объектов, а также момента генерации записи. В общем, подсистема контроля в сочетании с утилитой редукции/анализа данных даст вам с помощью предварительной выборки гибкость при выборе между системной производительностью и объемом пространства на диске, а также удобство полного контроля в сочетании с пост-выборкой.
Административные аспекты
Административное управление подсистемой контроля служит ключом к эффективному контролю. Если тщательно установить и аккуратно пользоваться подсистемой контроля, она будет мощным средством в деле поддержания секретности системы и идентификации возникающих проблем. Эта подсистема спроектирована в довольно завершенном виде в терминах охвата событий контроля - как со стороны действий ядра, так и со стороны использования системных утилит. Она спроектирована также для обеспечения надежности и для минимизации влияния на производительность системы в целом.
Насколько хорошо подсистема удовлетворяет вашим целям, зависит от правильного административного управления системой. Вы управляете согласованием надежности и производительности, используя параметры контроля. Неправильная установка может привести к низкой производительности, потере данных контроля или ко всему сразу. Например, решающее значение имеет установка маски событий контроля для управления типами событий, контролируемыми подсистемой. Так, если предварительная выборка событий не включает события регистрации, то проникновение в систему через коммутируемую линию связи может остаться незамеченным. Поэтому очень важно тщательно рассмотреть следующие три аспекта:
* задачи, связанные с производительностью
* задачи, связанные с надежностью
* требования к контрольному журналу
Задачи, связанные с надежностью
Так же, как и производительность системы, важна надежность выдаваемого контрольного журнала. В традиционных системах UNIX нет возможности сохранить целостность файловой системы в результате фатального сбоя системы. Это вызвано тем фактом, что ввод-вывод выполняется с помощью пула буферов, в которые запись (главным образом) ведется асинхронно. Так, изменения, внесенные в файлы, на самом деле могут оказаться не записанными на диск при фатальном сбое системы.
Это грустно, так как события, приводящие к фатальному сбою системы, представляют для вас наибольший интерес с точки зрения контроля. Очень хотелось бы минимизировать какую бы то ни было потенциальную потерю данных из подсистемы контроля в результате фатального сбоя системы. Для этого подсистема контроля использует механизм, называемый синхронным вводом-выводом, который выполняет немедленное обновление буферов сбора данных контроля и индексных дескрипторов файлов сбора данных, когда происходит их изменение. Это сводит к минимуму возможные потери данных в результате фатального сбоя системы.
Существует прямая связь между степенью надежности данных и производительностью подсистемы контроля. Контрольные записи, генерируемые механизмом контроля ядра, надежными прикладными программами и защищенными подсистемами, обычно имеют длину 40-60 байт. Если каждая запись пишется на диск синхронно, как только она передана подсистеме, результатом будет низкая производительность; система ввода-вывода переполняется из-за высокой скорости генерации записей. Выход состоит в том, чтобы буферизовать записи и писать их в контрольный журнал вместе через назначенные интервалы времени. Эти интервалы можно определить по истекшему времени или по пороговой величине накопленных данных. И здесь также выбор зависит от вас.
Требования к контрольному журналу
И, наконец, последнее, что важно для административного управления подсистемой контроля, - определить, что именно нужно контролировать. Можно использовать возможности предварительной выборки при генерации записей, чтобы контрольный журнал сконцентрировался на одном или нескольких событиях. Например, система может использоваться всего лишь маленькой группой людей, а по ночам простаивать. Кроме того, в нерабочее время предоставляются несколько коммутируемых линий связи. Возможно, вас интересует только учет того, кто и когда пользуется системой. В этом случае предварительную выборку можно использовать только для отслеживания событий входа в систему и выхода из нее. Попытки проникновения в систему со стороны неавторизованных пользователей будут зафиксированы как неудачные попытки регистрации.
Контроль можно также сосредоточить на конкретных пользователях или группах пользователей. Это позволит вам сконцентрироваться на лицах, подозреваемых в нарушении стратегии секретности. Чем меньше запрошено контроля, тем меньше подсистема контроля влияет на производительность системы. Полный контроль приводит к созданию пространной и подробной записи о системных событиях, но он требует и больше ресурсов для работы. Однако чаще оказывается удобнее зарегистрировать события и использовать средства редукции, чтобы потом отбросить ненужные записи, чем отказаться от сбора записей, действительно необходимых для анализа проблемы. Это решение зависит от степени секретности, которую вы намерены соблюсти.
Важно понять определение сессии контроля по отношению к подсистеме. Предполагается, что сессия соответствует интервалу времени с момента загрузки системы до момента ее выключения. Для сокращения объема записываемых в контрольный журнал данных в качестве одной из задач при проектировании подсистемы была установлена минимизация размера каждой контрольной записи. Следовательно, состояние процесса определяется последовательностью контрольных записей, а не указывается целиком в каждой записи.
При таком подходе экономия места и времени оказывается значительной, но это требует аккуратного административного управления во избежание ловушек. Если отключить подсистему контроля во время работы системы, а затем вновь включить, будет создана новая сессия. Сессия определяется как последовательность файлов сбора данных и уплотненных файлов, содержащих контрольные записи, связанные с конкретным интервалом времени. Это может привести к созданию двух (а возможно, и больше) наборов файлов контроля в одном жизненном цикле системы. Некоторые процессы, контролируемые во второй или последующей сессии, могут оказаться созданными во время первой сессии. Следовательно, сессия может не содержать все соответствующее состояние процесса, нужное для какого-либо процесса. В свою очередь, это может вызвать неполную редукцию записей. Это относится главным образом к именам файлов, причем как правило только к относительным именам файлов (а не абсолютным). Этого можно избежать, если выключать контроль только после останова системы.
Процедуры контроля
В данном разделе описывается, как устанавливать, инициировать, модифицировать и прекращать контроль системы. Доступ к каждой из этих функций осуществляется через sysadmsh. Выход на верхний уровень функций контроля производится выбором System->Audit; это следующие функции:
Enable/Disable Инициирование и прекращение контроля
Collection Выбор критерия контроля Формирование конфигурации подсистемы и управление контролируемыми событиями и пользователями. Кроме того, можно управлять параметрами установки, влияющими на производительность и надежность подсистемы и ее данные
Report Редукция данных контроля и составление отчетов Создание и сохранение выборочных файлов редукции, редукция сессий контроля с помощью файлов сбора данных и удаление сокращенных файлов после того, как они становятся ненужными
Files Сопровождение файла контрольных записей Проверка сессий контроля, накопленных в системе, архивирование сессий контроля на резервном носителе, восстановление ранее сохраненных сессий контроля, удаление ненужных сессий контроля, пуск и останов контроля по мере надобности
.
Процедура контроля состоит из трех этапов, описанных в последующих разделах:
1. Установка схемы сбора данных
2. Включение контроля
3. Генерация контрольных отчетов
Каталоги контроля
Файлы сбора данных, генерируемые подсистемой контроля, и уплотненные файлы, генерируемые демоном контроля, записываются в заданные вами каталоги. Сессия контроля может содержать файлы, записанные во множество различных каталогов. К концу сессии остаются только уплотненные файлы, так как файлы сбора данных удаляются подсистемой, когда они прочитаны демоном контроля. Вам не нужно отслеживать каталоги, в которые записываются файлы, поскольку эта информация имеется в журнальном файле сессии.
Вы можете увеличить производительность системы, поместив каталоги контроля в файловую систему, расположенную на отдельном физическом устройстве от остальных файловых систем. Это уменьшит соперничество за ресурсы диска. Кроме того, контроль требует значительного пространства, даже с учетом уплотнения. Когда мес-
та на диске становится мало, подсистема выдает предупреждение; если свободного пространства в файловой системе становится слишком мало, то подсистема выключает контроль. По этой причине подсистема и демон поддерживают несколько каталогов. При возникновении ошибки во время записи в каталог или при исчерпании места на диске подсистема и демон пытаются воспользоваться альтернативными каталогами, чтобы продолжить работу.
Каждое имя файла следует вводить с указанием абсолютного имени пути. Число каталогов, которые вы можете определить, ничем не ограничено. Если никакие каталоги не заданы, подсистема и демон создают все файлы в корневой файловой системе, используя зарезервированный каталог подсистемы контроля /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 Functions P. Process Modifications
Q. Audit Subsystem Events R. Database Events
S. Subsystem Events T. Use of Privilege
---------------------------------------------------------------------------
A. Запуск/Останов B. Вход/Выход из системы
C. Создать/Удалить процесс D. Сделать объект доступным
E. Отобразить объект в субъект F. Модификация объекта
G. Сделать объект недоступным H. Создание объекта
I. Удаление объекта J. Изменения DAC
K. Отказы DAC L. Действия оператора/Админ.
M. Недостаточные привилегии N. Отказы ресурса
O. Функции IPC P. Модификации процесса
Q. События подсистемы контроля R. События базы данных
S. События подсистемы T. Использование привилегий
---------------------------------------------------------------------------
Каждый тип события выводится на экран и соответствует букве, находящейся в верхней части экрана. Для событий, подлежащих контролю, тип события следует задать вместе с символом "Y". Типы событий, не подлежащие контролю, исключаются опцией "N". Для переключения ввода с "Y" на "N" и обратно пользуйтесь клавишей пробела. Для перехода от одного элемента к другому используйте клавиши перемещения курсора. Данную маску событий можно модифицировать и динамически изменять для текущей сессии контроля и/или записывать в файл параметров для использования в последующих сессиях контроля.
Выбор пользователя и группы
Поля User и Group можно использовать для динамического изменения выбора контроля в текущей сессии или для следующих сессий. Выбор пользователей и групп можно производить многократно в течение одной сессии. Если никакие пользователи и группы не выбраны, в результате все пользователи и группы будут исключены из данного выбора. Это означает, что все процессы в системе подлежат контролю.
Параметры подсистемы контроля
Вы можете изменить некоторые параметры контроля, чтобы настроить контроль в соответствии с требованиями системы. Некоторые из этих параметров связаны с проблемами компромисса между производительностью и надежностью, обсуждавшимися выше. Теперь это станет яснее. Имеются следующие параметры:
Write to disk... (Запись на диск)
Эти два параметра определяют частоту, с которой данные контроля синхронно сбрасываются в файл сбора данных контроля из внутренних буферов контроля. Сброс можно контролировать либо количеством данных, накопленных перед записью, либо истечением заданного интервала времени. Последняя возможность особенно полезна, когда генерируются небольшие объемы данных и частота генерации записей размазана по времени. Можно задать сброс и по счетчику байтов, и по истечению времени. Интервал времени всегда задается в секундах.
Плохой выбор этих величин может неблагоприятно повлиять на производительность. Слишком частые операции записи замедляют работу системы при чрезмерном трафике ввода-вывода.
С другой стороны, когда эти значения слишком велики, растет вероятность потери данных в случае фатального сбоя системы.
Рекомендуется при каждом заполнении одного внутреннего буфера делать сброс. Таким образом, обычно достаточно задать счетчик сброса равным 1024 (размер внутреннего буфера).
Wake up daemon... (Активизировать демон)
Данный параметр управляет демоном контроля. Этот демон постоянно читает с устройства контроля и получает записи, помещенные в файлы сбора данных. Затем эти записи уплотняются и записываются в уплотненные файлы, которые впоследствии подвергаются редукции. Для получения максимальной эффективности алгоритма уплотнения демону следует читать блоки данных размером от 4К до 5К байт. Для этого нужна специальная обработка в подсистеме, так как обычно операция чтения возвращает управление, когда доступны какие-либо данные, а не ждет, когда накопится определенный объем данных. Для максимальной эффективности этот параметр должен лежать в диапазоне от 4096 до 5120 байт. По умолчанию принимается величина 4096 байт.
Collection buffers (Буферы сбора данных)
Этот параметр позволяет задать число буферов сбора данных, используемых подсистемой. Она использует эти внутренние буфера для сбора данных контроля, записываемых в файл сбора данных. Для увеличения эффективности системы используется несколько буферов, так как все процессы совместно используют буферное пространство при попытках занесения записи. При наличии нескольких буферов процессы могут отложить записи на хранение и продолжать выполнение без блокировки, даже если на предыдущих буферах выполняется ввод-вывод. Нужно как минимум два буфера. Большинство систем не могут эффективно использовать более 4-6 буферов без проблем с производительностью. Не существует вполне определенного способа вычисления оптимального числа буферов. В общем случае задавайте эту величину исходя из ожидаемой загрузки процессами системы.
Collection/Audit output file switch...
(Переключение выходных файлов контроля/файлов сбора данных)
Эти два параметра позволяют задать максимальный размер, которого могут достигать файлы сбора данных и уплотненные файлы перед созданием нового файла. Если для обоих параметров выбрать маленькие значения, это приведет к чрезмерному числу переключений файлов. Так как уплотненные файлы являются постоянными, это также может вызвать обилие небольших файлов в системе. Если выбрать слишком большие значения, это создаст ситуацию, при которой файлы сбора данных контроля будут использовать много места на диске, даже если они будут частично считаны демоном контроля, что должно было бы вызвать их удаление. Размером уплотненных файлов контроля можно управлять потому, что эти файлы остаются в системе до редукции или удаления. Желательно, чтобы эти файлы имели размер, приемлемый для работы с ними, в том числе для их легкого сохранения и восстановления. По умолчанию для файлов сбора данных берется значение 50К байт, а для уплотненных файлов - 1 мегабайт. Убедитесь, что максимальный размер, выбранный для уплотненных файлов, не превышает установленной в системе величины ulimit, контролирующей максимальный размер, допустимый для пользовательского файла.
Compacted audit output files
(Уплотненные выходные файлы контроля)
Эта опция предусмотрена на случай, если нужно иметь и неуплотненные файлы контроля. Особой необходимости использовать эту опцию нет, так как уплотнение не требует много дополнительного времени на обработку, а итоговая экономия места на диске обычно больше 60 процентов. Алгоритм уплотнения содержится в пользовательском процессе демона контроля, а не выполняется в ядре подсистемы.
.
Enable audit on system startup
(Включить контроль при запуске системы)
Если ответ положительный, то в результате контроль будет начинаться автоматически при каждой перезагрузке системы.
Это поле выходит на экран только через опцию View; оно устанавливается в соответствии с тем, был ли контроль включен или выключен. Если контроль был выключен, то при запуске он будет отключаться.
Shutdown gracefully on disk full
(Выполнить постепенный останов при заполнении диска)
Эта опция позволяет системе выполнить автоматический останов, если она исчерпала пространство на диске; это помогает избежать порчи данных.
Change parameters for this/future session
(Изменить параметры для данной/следующей сессии)
Последние две опции на экране позволят вам динамически изменять текущую сессию и/или вносить изменения в постоянную часть файла параметров контроля для следующих сессий.
Текущая статистика
Последняя опция, предусмотренная в меню Collection, - это получение статистики текущей сессии контроля. Сюда входит информация о номере текущей сессии, количестве файлов сбора данных и уплотненных файлов, количестве записей, созданных механизмом контроля ядра, и записей, созданных прикладными программами, и др. Если в данный момент контроль не действует, статистика не выводится.
Пример распечатки Summary:
+---------------------------------------------------------------
| *** Audit Subsystem Statistics ***
| (Статистика подсистемы контроля)
| Current Audit Session-6 (Текущая сессия контроля - 6)
| Current Collection File Sequence Number-1488
| (Порядковый номер текущего файла сбора данных)
| Total count of audit data written: 7659433
| (Общий счетчик записанных данных контроля)
| Total count of audit records written: 156666
| (Общий счетчик записанных контрольных записей)
| Audit records written by applications: 81
| (Контрольные записи, сделанные прикладными программами)
| Audit records written by system calls: 155083
| (Контрольные записи, сделанные системными вызовами)
| System calls not selected for audit: 751889
| (Системные вызовы, не отобранные для контроля)
| Total number of audit device reads: 2977
| (Общее число операций чтения на устройстве контроля)
| Total number of audit device writes: 324
| (Общее число операций записи на устройстве контроля)
| Total number of collection files: 1489
| (Общее число файлов сбора данных)
|
.
Включение/выключение контроля
Чтобы включить или выключить контроль, используйте следующие выборы в sysadmsh:
System->Audit->Enable
System->Audit->Disable
Функция включения, используя текущий файл параметров контроля, выполняет инициализацию подсистемы. Функция выключения доступна из того же меню и вызывает постепенный выход из контроля (когда все файлы сбора данных прочитаны демоном и уплотнены). Затем демон прекращает работу, оставляя лишь журнальный файл сессии контроля и уплотненные файлы сессии.
Помните, что если выключить контроль, а затем вновь его включить, не перезагрузив систему, то это может вызвать потерю некоторых данных процесса, нужных для поддержания состояния процесса. Если контроль прекращен для модификации некоторых параметров, учтите, что большинство параметров подсистемы можно модифицировать и в процессе контроля. Для обеих функций - включения и выключения - предусмотрены экраны для подтверждения, которое нужно сделать до завершения функции в sysadmsh. Когда контроль включается или выключается, на экран выходит сообщение о состоянии контроля в момент перезагрузки; если контроль выключен, то при запуске системы он будет выключен, а если включен, то он будет вновь включен.
Сопровождение файлов контроля
Функции сопровождения файлов контроля доступны в sysadmsh при следующем выборе:
System->Audit->Files
Доступны следующие файловые функции:
List Вывод списка файлов сессии контроля в системе
Backup Дублирование файлов сессии контроля на резервном носителе
Delete Удаление файла сессии контроля
Restore Восстановление файлов сессии контроля с резервного носителя
Сессия контроля состоит из журнального файла сессии и группы уплотненных файлов, сгенерированных между моментами включения и выключения подсистемы контроля. Каждый файл сбора данных и уплотненный файл, созданный во время сессии, получает уникальный номер от этой сессии. После завершения сессии остается только журнальный файл и уплотненные файлы. Функции сопровождения файлов проверяют, какие сессии еще имеются в системе, и дают возможность удалить уже не нужные сессии.
.
Вывод списка контрольных записей
Этот выбор дает немедленный ответ: выводится список файлов, доступных в каталогах контроля.
Дублирование контрольных записей
Поскольку сессии контроля требуют много места на диске, часто оказывается необходимым внести данные контроля в архив, а затем либо сократить их, либо восстановить на некоторый период времени, если они нужны для анализа проблем, которые нельзя выявить немедленно. Такую возможность дает интерфейс дублирования/восстановления. Опция Backup требует в качестве ввода номер сессии. Его можно получить, сгенерировав контрольный отчет (см. ниже). Выбрав дублирование, вы должны выбрать и выходное устройство для дублирования. Им может служить любой съемный носитель, доступный в системе.
Замечание