Жанр: Учеба
SCO: Пособие администратора системы Unix
...тствует определенный выбор
в 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-10 -
Таблица 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
- 5-11 -
Пользователи, которым присвоены административные роли,
должны иметь определенные авторизации ядра, чтобы выполнять задачи,
требуемые подсистемой. Если вы используете общесистемные
авторизации ядра, принимаемые по умолчанию ("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. Кроме того, можно изменить любой параметр - и для отдельных
пользователей, и по всей системе. Изменение общесистемных
параметров описано в разделе "Конфигурация для ведения учета,
устанавливаемая по умолчанию" в главе "Административное управление
пользовательскими бюджетами". Информация о параметрах
для отдельных пользователей приведена в разделе "Управление учетом"
той же главы.
Управление системным доступом
Одним из важных аспектов работы в надежной системе является
выявление потенциальных проблем, относящихся к секретности. Ограничительные
механизмы подразделяются на три категории, каждая
из которых может быть приспособлена к конкретным требованиям и
сопровождаться отчетами:
* Статус пароля
* Активность терминала
* Активность начальной регистрации
Каждая из этих областей имеет важное значение для точного
определения потенциальных проблем с секретностью. Процедуры для
выполнения этих отчетов можно найти в разделе "Генерация отчетов
об активности" в главе "Административное управление пользовательскими
бюджетами". В последующих подразделах поясняется, как
реализуются эти ограничения.
- 5-12 -
Статус пароля
В качестве модели для введения ограничений на пароли был
использован документ "Руководство по использованию паролей"
(Password Management Guideline) Министерства обороны; поэтому
пользователи подвергаются более серьезной проверке на пароли,
чем в менее надежных системах UNIX. Администратор аутентификации
может либо разрешить пользователям самим выбирать себе пароли,
либо обязать систему генерировать для них пароли. Пароль, будучи
однажды выбран, может подвергнуться большому числу элементарных
проверок, что опять же зависит от Администратора аутентификации.
Для паролей существует три уровня действительности, что является
расширением реализации процесса старения пароля в стандартной
системе UNIX. Пароли остаются действительными, пока не
настанет достигнут его срок истечения действия. Когда срок действия
пароля истекает, пользователь (если ему разрешено это делать)
получает приглашение на изменение своего пароля. Если
пользователю не разрешено менять свой пароль, администратор должен
назначить новый пароль.
Пароли считаются expired, пока не завершится их жизненный
цикл. Мертвый пароль вызывает блокирование пользовательского
бюджета. Снять эту блокировку может только Администратор аутентификации,
используя выбор Accounts в sysadmsh. Если пользователю
не разрешено менять пароль, нужно назначить новый.
Во избежание повторного использования паролей Администратор
аутентификации может также установить минимальный срок изменения
для пароля, до которого пользователь не имеет права менять пароли.
Все эти параметры можно изменить - и по всей системе (база
данных системных параметров, принимаемых по умолчанию), и для
отдельных пользователей (база данных защищенных паролей). Общесистемное
изменение параметров паролей описано в разделе "Изменение
ограничений на пароли, принятых по умолчанию" в главе "Административное
управление пользовательскими бюджетами" настоящего
руководства, а полное описание процедур изменения паролей
приведено в разделе "Изменение пароля пользователя или параметров
пароля" той же главы.
Отчеты по паролям можно использовать для предотвращения
блокировки пользовательских бюджетов; эта ситуация очень неприятна,
если администратор системы отсутствует. Если в вашей системе
не принято ежедневное присутствие администраторов, вы имеете
право претендовать на соответствующее увеличение параметра
жизненного цикла пароля.
Активность терминала
Терминал - это вход в вашу систему. Помимо использования
паролей бюджетов, терминалы можно защитить от попыток проникновения
в систему. Можно задать максимальное число неудачных попыток
регистрации, которые обычно связаны с попытками угадать па.
- 5-13 -
роль бюджета. Терминалы, для которых превышено максимально
допустимое число попыток, будут заблокированы; снимать блокировку
должен Администратор бюджетов. Кроме того, можно задать интервал
времени, который должен пройти между попытками регистрации,
что также может помочь пресечь попытки угадать пароль.
(Аналогичные ограничения можно ввести для бюджетов, отличных от
терминалов.) О том, как изменять или проверять ограничения для
терминала, см. раздел "Управление регистрацией терминала" в главе
"Административное управление пользовательскими бюджетами"
настоящего руководства.
Активность начальной регистрации
Как и в случае терминалов, у пользовательских бюджетов есть
параметры, связанные с числом попыток регистрации и интервалом
для повторной попытки, которые относятся к регистрации в бюджете,
а не в терминале. О том, как изменять или проверять эти ограничения,
см. раздел "Изменение ограничений при регистрации,
принятых по умолчанию" в главе "Административное управление
пользовательскими бюджетами" настоящего руководства.
- 5-14 -
ИСПОЛЬЗОВАНИЕ ПОДСИСТЕМЫ КОНТРОЛЯ
Подсистема контроля регистрирует события в системе, связанные
с секретностью, записывая их в контрольный журнал, который
затем можно просмотреть. В контрольных журналах, выдаваемых подсистемой,
можно фиксировать проникновение в систему и неправильное
использование ресурсов. Подсистема контроля спроектирована в
соответствии с задачами контроля, определяемыми Национальным
центром защиты данных компьютеров США.
Контроль позволяет просматривать собранные данные для изучения
образцов доступа к объектам и наблюдения за действиями отдельных
пользователей и их процессов. Попытки нарушения защиты и
механизмов авторизации контролируются. Подсистема контроля дает
высокую степень гарантии обнаружения попыток обойти механизмы
обеспечения безопасности. Поскольку события, связанные с секретностью,
контролируются и поддаются учету вплоть до выявления
конкретного пользователя, подсистема контроля служит сдерживающим
средством для пользователей, пытающихся неправильно воспользоваться
системой.
Подсистема контроля использует системные вызовы и утилиты
для классификации действий пользователей, подразделяя их на типы
событий. Это можно использовать для выборочной генерации и редукции
контроля. Один из этих типов событий, Отказ дискреционного
доступа (DAC), регистрирует попытки такого использования объектов,
которое не допускается разрешениями для этого объекта.
Например, если пользовательский процесс пытается писать в файл
"только для чтения", регистрируется событие Отказа DAC, показывающее,
что процесс пытался произвести запись в файл, на что у
него не было права. Если просмотреть контрольный журнал, то легко
будет заметить повторяющиеся попытки доступа к файлам, на которые
не выданы разрешения.
Для эффективности данных контроля существенна возможность
учета пользователей, выполняющих действия, подлежащие контролю.
Когда пользователи пытаются войти в систему, они должны пройти
процесс идентификации и аутентификации, прежде чем им будет предоставлен
доступ в систему. Механизм секретности снабжает каждый
процесс, создаваемый пользователем, постоянным индикатором идентичности
- регистрационным идентификатором пользователя (LUID).
Этот идентификатор сохраняется невзирая на переходы от одного
пользовательского бюджета к другому с помощью таких команд, как
su(C). Каждая контрольная запись, генерируемая подсистемой, содержит
LUID наряду с эффективным и реальным идентификаторами
пользователя и группы для процесса. В итоге оказывается возможным
строгий учет действий пользователей.
Подсистема контроля управляется Администратором контроля.
Будучи Администратором контроля, вы обладаете полным контролем
над событиями, выбранными для генерации контрольных записей, над
значениями параметров подсистемы контроля и над последующей редукцией
и анализом данных контроля.
- 5-15 -
Компоненты подсистемы контроля
Подсистема контроля состоит из четырех главных компонентов:
* Механизм контроля ядра
* Драйвер устройства контроля (/dev/audit)
* Демон уплотнения данных контроля - auditd(ADM)
* Интерфейс контроля sysadmsh
Существует несколько надежных системных утилит, которые,
хотя на самом деле и не являются собственно частью подсистемы
контроля, отвечают за занесение контрольных записей в контрольный
журнал (например, login(M)).
Механизм контроля ядра
Механизм контроля ядра является центральным в подсистеме
контроля. Этот механизм генерирует контрольные записи, исходя из
активности пользовательских процессов, с помощью системных вызовов
ядра. Каждый системный вызов ядра содержит строку в таблице
подсистемы, где указано, связан ли этот вызов с вопросами секретности,
и если это так, то какому типу события он соответствует.
Кроме того, используется таблица кодов ошибок, позволяющая
классифицировать системные вызовы на конкретные события, связанные
с секретностью. Механизм контроля ядра выдает внутренний вызов
в драйвер устройства для занесения записи в контрольный журнал.
Например, системный вызов open(S) классифицируется как событие
Сделать объект доступным. Если пользователь blf выполняет
open(S) для /unix и делает это успешно, генерируется контрольная
запись об этом событии. Однако если системный вызов заканчивается
неудачно из-за того, что blf запросил в open(S) доступ по записи,
не имея разрешения на запись в этот файл, это действие
классифицируется как событие Отказ дискреционного доступа для
blf и объекта /unix. Следовательно, системный вызов можно отобразить
в несколько типов событий, в зависимости от объекта, к
которому осуществляется доступ, и/или результата вызова. Поэтому
возникает возможность выборочного контроля системных вызовов, в
зависимости от типов событий, которые вы сделаете доступными.
Некоторые системные вызовы не относятся к секретности. Например,
getpid(S) получает идентификатор процесса и не определяет
событие, связанное с секретностью. Таким образом, этот системный
вызов не подлежит контролю.
Драйвер устройства контроля
Драйвер устройства контроля выполняет следующие функции:
прием контрольных записей от механизма контроля ядра и от надежных
утилит; создание и запись промежуточных файлов контрольного
журнала; предоставление данных контрольного журнала демону контроля
для уплотнения; обеспечение выборочной генерации контрольных
записей на основе типов событий, идентификаторов пользователей
и идентификаторов групп.
- 5-16 -
Драйвер устройства обеспечивает интерфейсы open(S),
close(S), read(S), write(S) и ioctl(S), как и прочие символьные
устройства. Однако устройство контроля может быть открыто только
процессами, обладающими авторизациями ядра configaudit и/или
writeaudit. Это ограничивает доступ к устройству контроля, разрешая
его только для надежных утилит, таких как интерфейсы демона
контроля и Администратора контроля. В устройство контроля могут
писать несколько процессов одновременно. Это устройство производит
объединение записей в контрольный журнал. Читать с
устройства может только один процесс - демон контроля.
Драйвер устройства контроля ведет контрольный журнал в виде
набора файлов сбора данных контроля. Каждый раз, когда вы включаете
контроль, начинается новая сессия контроля. При ее запуске
подсистема создает файл сбора данных, в который заносятся контрольные
записи. Когда файл сбора данных достигает определенного
размера, установленного администратором, подсистема создает новый
файл сбора данных и начинает писать в него. Поэтому контрольный
журнал можно рассматривать как постоянно увеличивающийся
последовательный файл, даже если используется несколько файлов
сбора данных. Именно в таком виде контрольный журнал рассматривается
демоном контроля, потому что он читает с устройства и получает
записи из контрольного журнала. При достижении конца файла
сбора данных подсистема выполняет соответствующее переключение
на новый файл сбора данных. Все это прозрачно для демона.
Демон контроля
Демон контроля auditd(ADM) - это надежная утилита, выполняющаяся
как фоновый демон-процесс при включении контроля. Этот
демон - единственный, кто читает с устройства контроля, которое
в свою очередь представляет демону блоки записей из файлов сбора
данных контроля. Демону безразлично, что контрольный журнал
расслаивается на множество файлов сбора данных. Драйвер устройства
контроля удовлетворяет запросы на чтение, поступающие от демона,
и обрабатывает переключение и удаление файлов сбора данных
по мере надобности.
Главное предназначение демона состоит в предоставлении механизма
уплотнения данных и регистрации для сессии контроля. Демон
также выполняет функцию поддержки защищенных подсистем, позволяя
им писать в подсистему контрольные записи. В зависимости
от выбранного вами критерия формирования контрольных записей, в
системе может быть сгенерировано огромное количество данных
контроля. В типичном случае однопользовательской системы генерация
200 килобайтов данных контроля за час не будет выглядеть необычно.
Поэтому демон предоставляет механизм уплотнения для сжатия
данных контроля в упакованный формат записи, которая сохраняется
в файле уплотнения контроля.
Второй функцией демона является обеспечение журнального
файла, описывающего текущую сессию контроля. Журнальный файл содержит
информацию о количестве контрольных записей, доступных в
уплотненных файлах вывода в сессии; время запуска и останова
сессии; а также другие индикаторы состояния сессии контроля. Как
только драйвер устройства контроля переключает файлы сбора дан.
- 5-17 -
ных при достижении ими размеров, установленных администратором,
демон может создать несколько уплотненных файлов, чтобы не допустить
увеличения одного файла до размеров, недоступных управлению.
Вы также это контролируете. Кроме того, уплотненные файлы,
записанные демоном, можно разместить в любом каталоге, определенном
администратором. По этим причинам ведется журнальный
файл - чтобы иметь журнал с уплотненными файлами, которые можно
использовать для последующей редукции данных.
Третья функция демона контроля - выполнять роль программы
интерфейса с драйвером устройства контроля для занесения контрольных
записей из защищенных подсистем, не имеющих авторизации
writeaudit. Так как эти подсистемы не могут осуществлять доступ
непосредственно к драйверу устройства контроля, но могут образовать
интерфейс с демоном с соблюдением секретности, то демон выполняет
занесение контрольной записи прикладной программы в подсистему.
Доступ к контролю через sysadmsh
sysadmsh предоставляет простые возможности для установки и
сопровождения подсистемы контроля. Это позволяет администратору
выполнять установку и инициализацию, модифицировать параметры
подсистемы, сопровождать подсистему (резервное дублирование,
восстановление и т.д.) и выполнять редукцию как общих, так и выборочных
данных контроля.
Средство редукции/анализа данных
sysadmsh также включает в себя утилиту редукции/анализа
данных, которая облегчает исследование контрольных журналов предыдущих
сессий контроля или текущей сессии контроля. Используя
журнальный файл, созданный демоном контроля, утилита редукции
может идентифицировать все уплотненные файлы, нужные для редукции
сессии контроля. Так как уплотненные файлы имеют сжатый формат,
программа редукции содержит подпрограммы, необходимые для
развертывания файлов.
Для обеспечения эффективного анализа данных контроля утилита
редукции позволяет задавать для выборочной редукции данных
определенные типы событий, идентификаторы пользователей, идентификаторы
групп и имена объектов. Более того, вы можете задать
интервал времени, в течение которого должен производиться поиск
записей, удовлетворяющих выбранному критерию. Если какая-либо
запись не попадает в этот интервал, она отбрасывается в данной
редукции.
Например, вы можете выполнять редукцию данных, выбирая событие
Отказа DAC для пользователя с идентификатором blf, ведущего
поиск объекта /unix. Будут распечатаны только те записи, которые
отражают попытки доступа blf к /unix, отвергнутые ввиду
отсутствия нужных разрешений. Это образует мощный механизм для
идентификации событий секретности, представляющих актуальный интерес,
без анализа всего контрольного журнала.
- 5-18 -
Методология контроля
В данном разделе описывается, как функционирует подсистема
контроля, какие критерии используются при сборе данных, и как
требования контроля влияют на производительность системы.
Авторизации контроля
С подсистемой контроля связаны три авторизации:
configaudit, writeaudit и suspendaudit.
Авторизация configaudit позволяет устанавливать параметры
контроля для всех пользователей системы.
Авторизация writeaudit позволяет регистрировать специфическую
информацию в контрольном журнале.
Авторизация suspendaudit отключает всякий контроль.
Источники контрольных записей
Контрольный журнал содержит содержит информацию о событиях
в системе, связанных с секретностью. Эффективный контроль охватывает
не только запросы на системные вызовы, поступающие от
пользовательских процессов, но и определенные события, такие,
как вход в систему, выход из системы, неудачные попытки регистрации.
Эти события критичны для определения того, кто выполнял
доступ к системе, в какие моменты времени, с какого терминала, и
какие именно действия были выполнены. Неудачные попытки регистрации
невозможно контролировать на уровне ядра, поскольку ему
неизвестно, что конкретно делает прикладная программа. Таким образом,
следует дать возможность генерировать контрольные записи
и некоторым утилитам, влияющих на секретность, например login.
Контрольные записи генерируются из трех источников (описываемых
в последующих разделах):
* механизм контроля ядра
* надежные прикладные процессы
* авторизованные подсистемы
Механизм контроля ядра
Значительная часть контрольных записей, хранящихся в контрольном
журнале, генерируется механизмом контроля ядра. Этот
раздел подсистемы контроля генерирует записи в ответ на системные
вызовы пользовательских процессов, отображаемые в события,
связанные с секретностью. Некоторые системные вызовы, например
open(S), отображаются в несколько событий секретности, в зависимости
от аргументов пользователя и от состояния открываемого
файла. Если open(S) вызывается с флагом O_CREAT, файл создается,
если он не существовал. Если задан флаг O_TRUNC, выполняется
- 5-19 -
усечение файла до нулевой длины, если он существует. Это показывает,
как вызов open(S) может отобразиться в одно из трех различных
событий: Сделать объект доступным, Создание объекта или
Модификация объекта.
Важную роль в определении события играют также коды ошибок.
Ошибки при выполнении системных вызовов, указывающие, что доступ
или разрешение отвергнуты, равно как и проблемы потребления ресурсов,
отображаются в конкретные типы событий. Механизм контроля
ядра в конце системного вызова определяет, какому классу событий
принадлежит вызов, и задали ли вы контроль этого события.
Более того, данный механизм может также применить дополнительные
критерии выбора, например, идентификатор пользователя или идентификатор
группы. Таким о
...Закладка в соц.сетях
