Жанр: Учеба
SCO: Пособие администратора системы Unix
... Для системного вызова из этого списка выходная запись использует
общую маску записи, изображенную на Рисунке 5-3. Данный
пример иллюстрирует выходную запись для успешного системного вызова
setuid(S).
Process ID: 6381 Date/Time: Tue Mar 15 11:25:19 1988
Luid: blf Euid: blf Ruid: root Egid: root Rgid: root
Event type: Modify process (Тип события: Модифицировать процесс)
System call: Setuid
Result: Successful
Рисунок 5-3. Запись системного вызова setuid(S)
Аналогичным образом на следующем рисунке показана выходная
запись системного вызова setuid(S), не выполнившегося из-за отсутствия
разрешения для файла. Заметьте, что классификация типа
события здесь другая, и что ошибка отражается в поле результата.
Process ID: 6381 Date/Time: Tue Mar 15 11:25:19 1988
Luid: blf Euid: blf Ruid: blf Egid: guru Rgid: guru
Event type: Modify process
System call: Setuid
Result: Failed (EPERM) -Not owner (Неудача: Не владелец)
Рисунок 5-4. Выходная запись при отказе доступа
Многие системные вызовы этой группы генерируют в выходной
записи дополнительную информацию, уточняющую данные контрольного
журнала. Системные вызовы семафора, разделяемой памяти, очереди
- 5-39 -
сообщений и security(S) перегружены. Они отображаются во множество
функций. Эти контрольные записи идентифицируют конкретную
выполняемую функцию и затрагиваемый объект (например, разделяемую
память). Вызовы close(S), dup(S) и fcntl(S) работают с дескрипторами
файлов, полученными из имен путей. Выходная запись,
указывающая dup(S) для дескриптора файла, не будет очень нужна,
так как она не идентифицирует файл однозначно. Таким образом,
reduce соотносит дескриптор файла с именем пути и проставляет
это имя в записи.
Хотя системные вызовы read(S) и write(S) включены в список
на Рисунке 5-3, они контролируются только в определенных обстоятельствах,
и для них не выделяется специальная выходная запись.
Оба этих вызова контролируются только при первом выполнении для
файла. Последующие операции чтения и записи не контролируются,
так как они не добавляют никакой информации. Контрольные записи
используются в reduce для отслеживания состояния файла. Когда
файл закрывается вызовом exec(S), exece(S), close(S) или
exit(S), в запись системного вызова для действия, вызвавшего
закрытие файла, включается имя объекта и индикатор чтения или
записи. Это иллюстрируется Рисунком 5-5.
Process ID: 421 Date/Time: Sat Mar 5 17:15:09 1988
Luid: blf Euid: blf Ruid: blf Egid: guru Rgid: guru
Event type: Make object unavailable (Сделать объект недоступным)
System call: Close
File Access-Read: Yes Written: No
(Доступ к файлу по чтению: Да Записан: Нет)
Object: /tmp/datafile
Result: Successful
Рисунок 5-5. Запись системного вызова close(S)
Вторая группа системных вызовов, показанная на Рисунке 5-6,
включает в состав выходной записи имена путей. Имя пути представляет
назначение системного вызова. Записи для двух системных
вызовов (link(S) и mount(S)) на самом деле содержат по два имени
пути.
open unlink creat
exec chdir mknod
chown chmod stat
umount exece chroot
link mount
Рисунок 5-6. Системные вызовы с именами путей
Каждый из этих системных вызовов использует одно или несколько
имен путей в качестве аргументов вызова. Имена путей
контролируются и играют важную роль в процессе редукции. Выходные
записи для этих вызовов указывают имя объекта, с которым выполнялись
действия. Это имя также сохраняется программой редукции
и там, где это нужно, сопоставляется дескриптору файла,
- 5-40 -
возвращаемому данным системным вызовом. Это соответствие используется
другими системными вызовами, такими как dup(S), которые
работают с файлом, но не содержат имя пути. На Рисунке 5-7 приведена
выходная запись, сгенерированная в результате системного
вызова creat(S). Формат записи представляет собой базовый формат,
дополненный именем пути.
Process ID: 64 Date/Time: Sat Mar 5 23:25:09 1988
Luid: root Euid: root Ruid: root Egid: root Rgid: root
Event type: Object creation (Создание объекта)
System call: Creat
Object: /tmp/daemon.out
Result: Successful
Рисунок 5-7. Выходная запись с именем пути
Все вызовы этой группы пользуются одним и тем же форматом
имени пути. Два вызова (link(S) и mount(S)) используют два имени
пути: источник и назначение. Типичная запись, выдаваемая системным
вызовом link(S), показана на Рисунке 5-8.
Process ID: 14231 Date/Time: Thu Mar 16 03:25:39 1988
Luid: lp Euid: lp Ruid: lp Egid: lp Rgid: lp
Event type: Object creation
System call: Link
Source: /tmp/printfile
Target: /usr/spool/lp/lp3014
Result: Successful
Рисунок 5-8. Выходная запись с двумя именами путей
Два других системных вызова этой группы генерируют специальные
выходные записи. Это вызовы chown(S) и chmod(S), которые
используются для изменения разрешений дискреционного доступа и
смены владельца объекта. Так как эти действия имеют отношение к
секретности, в записи выводятся старые и новые значения владельца
объекта, имени группы и режима. На Рисунке 5-9 показана выходная
запись от системного вызова chmod(S).
Process ID: 6841 Date/Time: Sat Mar 5 13:25:09 1988
Luid: blf Euid: blf Ruid: blf Egid: guru Rgid: guru
Event type: Discretionary Access Change
(Изменение дискреционного доступа)
System call: Chmod
Object: /tmp/demo/newfile
Old values: Owner-blf Group-guru Mode-100600
(Старые значения: Владелец... Группа... Режим...)
New values: Owner-blf Group-guru Mode-100666 (Новые знач.)
Result: Successful
Рисунок 5-9. Запись системного вызова chmod(S)
- 5-41 -
Контрольные записи прикладных программ
Имеется шесть различных типов контрольных записей, генерируемых
прикладными программами. Форматы этих записей аналогичны.
В отличие от системных вызовов, любая запись одной из этих категорий
всегда имеет идентичный формат, хотя информация варьируется.
Категории записей следующие:
* События входа в систему и выхода из нее
* События подсистемы контроля
* События пользовательского пароля
* События авторизованной подсистемы
* События защищенной базы данных
* События блокировки терминала и пользовательского бюджета
Каждая запись содержит определенную информацию, общую для
всех выходных контрольных записей. Сюда входят идентификатор
процесса, время и дата, а также тип события контроля. Содержание
остальной части выходной записи зависит от ее типа. Поля, зависящие
от записи, описываются в последующих разделах.
Запись входа в систему и запись выхода из системы
Все попытки зарегистрироваться в системе контролируются
программой регистрации. Это касается как успешных, так и неудачных
попыток. Тем самым собирается важная информация о доступах
пользователей в систему и о попытках доступа. Вы можете использовать
контрольные записи входа и выхода из системы, чтобы определить,
кто на самом деле работает в системе. Они также полезны
в случае повторных попыток проникновения в систему. В операционной
системе поддерживается возможность блокировки терминала после
определенного числа попыток, и это событие также можно поставить
на контроль. Итак, у вас есть все средства, необходимые для
отслеживания (и предотвращения) доступа в систему.
Каждая запись регистрации содержит индикатор, обозначающий
конкретное действие, которое контролировалось. Существует три
возможности: успешная регистрация, неудачная регистрация, выход
из системы. Все успешные входы и выходы приводят к формированию
выходной контрольной записи, указывающей пользовательский бюджет
и терминал регистрационной сессии. Если попытка неудачна, имя
пользователя не имеет значения - ведь попытка не удалась. В этом
случае выводится только терминал, на котором была предпринята
попытка, а также поля базовой записи. На Рисунке 5-10 показан
вывод в случае успешной регистрации.
- 5-42 -
Process ID: 2812 Date/Time: Fri Mar 4 10:31:14 1988
Event type: Login/Logoff Activity
(Тип события: Вход в систему или выход из системы)
Action: Successful Login (Действие: Успешный вход)
Username: blf (Имя пользователя:...)
Terminal: /dev/tty2 (Терминал:...)
Рисунок 5-10. Выходная запись успешного входа в систему
Запись пользовательского пароля
Все попытки модифицировать пароль пользовательского бюджета
(и успешные, и неудачные) тщательно контролируются подсистемой
авторизации. По соображениям секретности контрольные записи для
этих событий не содержат текста пароля, но только указывают бюджет
и контролируемое действие. Все действия подразделяются на:
успешное изменение пароля, неудачное изменение, отсутствие разрешения
на изменение пароля. На Рисунке 5-11 показана контрольная
запись для случая неудачной попытки изменения пароля.
Process ID: 7314 Date/Time: Tue Mar 1 18:30:44 1988
Event type: Authentication database activity
(Работа с базой данных аутентификации)
Action: Unsuccessful password change
(Неудачное изменение пароля)
Username: blf
Рисунок 5-11. Контрольная запись для неудачного изменения пароля
Запись защищенной базы данных
Программы, сопровождающие и модифицирующие защищенные базы
данных системы, контролируют все попытки доступа и нетривиальные
ситуации, связанные с базами данных. Здесь может идти речь о
множестве проблем, начиная с проблем целостности и кончая отказов,
связанных с секретностью. Помимо заголовка записи и названия
контролируемого действия, в выводе содержится имя программы,
обнаружившей данную проблему, название объекта, с которым проблема
связана, ожидаемые и фактические значения, а также действие
и результат события.
Process ID: 7314 Date/Time: Tue Mar 1 18:30:44 1988
Event type: Authentication database activity
Command: authck
Object: Protected password database
(Объект: защищенная база данных паролей)
Value: Expected-0 Actual-0
(Значение: ожидаемое - 0, фактическое - 0)
Security action: /tcb/files/auth/code
(Действие, связанное с секретностью:...)
Result: extraneous file in protected password hierarchy
(Результат: посторонний файл в защищенной иерархии паролей)
Рисунок 5-12. Выходная запись для защищенной базы данных
- 5-43 -
Запись подсистемы контроля
События, затрагивающие работу подсистемы контроля, сами
очень тщательно контролируются. Выборы audit в sysadmsh и демон
контроля auditd генерируют контрольные записи для функций, которые
они поддерживают. Помимо этого, драйвер устройства контроля
также создает контрольные записи для запросов определенных функций.
Контролируются следующие функции:
инициализация подсистемы;
прекращение подсистемы;
модификация параметров подсистемы;
демон контроля включен;
демон контроля выключен;
останов подсистемы;
ошибка подсистемы.
Каждая выходная запись включает информацию общего заголовка,
а также индикатор контролируемой функции. Тем самым обеспечивается
точный учет всех попыток повлиять на работу подсистемы
контроля. На Рисунке 5-13 показана актуальная контрольная запись,
индицирующая запуск и инициализацию подсистемы.
Process ID: 517 Date/Time: Wed Mar 2 8:30:04 1988
Event type: Audit subsystem activity (Работа подсистемы контроля)
Action: Audit enabled (Контроль включен)
Рисунок 5-13. Выходная запись подсистемы контроля
Запись защищенной подсистемы
Каждая защищенная подсистема может генерировать контрольные
записи через демон контроля. Эти записи указывают на необычные
условия, обнаруженные подсистемой. Например, если подсистема
сталкивается с проблемами разрешений для файла или ей отказано в
обслуживании из-за нехватки памяти или других ресурсов, подсистема
генерирует сообщение о соответствующей ошибке. Эти записи
можно использовать, чтобы поддерживать безопасность системы.
Помимо обычного вывода заголовка записи, в записях подсистемы
содержится имя команды, действие и результат. Имя команды
относится к команде, обнаружившей несовместимость и сформировавшей
контрольную запись. Действие и результат описывают действия,
предпринятые подсистемой, и обнаруженную проблему. На Рисунке 514
показана контрольная запись, сгенерированная подсистемой.
Process ID: 2812 Date/Time: Fri Mar 4 10:31:14 1988
Event type: Authorized subsystem activity
(Работа авторизованной подсистемы)
Subsystem: System Administrator Subsystem
(Подсистема: Администратор системы)
Security action: Update /etc/rc
(Действие, связанное с секретностью: Обновление...)
Result: Cannot open for update
(Результат: Файл нельзя открыть для обновления)
Рисунок 5-14. Выходная запись авторизованной подсистемы
- 5-44 -
Запись терминала/пользовательского бюджета
Пользовательские бюджеты или терминалы могут оказаться заблокированными,
если число неудачных попыток регистрации в системе
превысит значение, хранящееся в базе данных авторизации. Например,
если терминал используется для входа в систему, результатом
чего является серия неудачных попыток регистрации, то программа
регистрации может заблокировать терминал после определенного
числа попыток. Аналогичным образом, если пользователь пытается
зарегистрироваться в бюджете, и ему это несколько раз не
удается, то пользовательский бюджет может быть заблокирован.
Блокировка бюджетов и терминалов не позволит осуществлять доступ
к ним до тех пор, пока Администратор системы не снимет блокировку.
Терминал или пользовательский бюджет могут быть заблокированы
при попытке проникновения в систему. Соответствующие контрольные
записи содержат обычную информацию заголовка, а также
идентификатор пользовательского бюджета или терминала.
Process ID: 517 Date/Time: Wed Mar 2 8:30:04 1988
Event type: System administrator activity
(Работа администратора системы)
Action: User account locked by system administrator
(Пользовательский бюджет заблокирован администратором системы)
Username: root (Имя пользователя: ...)
Рисунок 5-15. Выходная запись блокировки
пользовательского бюджета
Проблемные области подсистемы контроля
Ниже приведены описания ситуаций, в которых возникают проблемы,
связанные с контролем.
Пространство на диске
Подсистема контроля может сгенерировать большое число контрольных
записей. Хотя они и достаточно маленькие, но памяти могут
потребовать очень много. Поэтому при административном управлении
системой следует соблюдать осторожность. Контрольная информация
должна направляться на диски, где имеется достаточно
доступного пространства. В подсистеме имеются встроенные механизмы
защиты, которые выдают предупреждения, когда в устройстве
контроля остается мало места. Если ситуация не выправляется и
объем оставшегося пространства на диске становится меньше некоторого
порогового значения, то подсистема пытается переключиться
на новый каталог контроля. Поэтому альтернативные каталоги контроля
следует размещать в других файловых системах. Когда подсистема
наталкивается на ошибку ввода-вывода, она пытается направить
контроль в новый каталог из списка.
- 5-45 -
Фатальные сбои системы
В большинстве систем рано или поздно происходит фатальный
сбой, невзирая на все усилия по обеспечению устойчивости. В таком
случае существует возможность потери данных в контрольном журнале
из-за несогласованности буферизованных выходных записей и индексных
дескриптов файлов. Подсистема контроля делает все возможное,
чтобы воспользоваться синхронным вводом-выводом для таких
критичных операций, как сброс буферов, индексных дескрипторовфайлов
и каталогов. Однако нет гарантии, что данные во всех случаях
попадут на диск. В особенности это касается случаев, когда сбой
на диске вызывает фатальный сбой системы.
После перезагрузки вы, что вполне вероятно, можете обнаружить
повреждение файловой системы на файлах контрольного журнала.
У вас может не оказаться другого выбора, кроме как удалить
файлы контроля и снять проблему. Это немного компрометирует
контрольный журнал, но зато устраняет все проблемы по восстановлению
файловой системы после любого нарушения.
Сообщения подсистемы
Подсистема контроля обладает устойчивостью. Она обрабатывает
ошибки ввода-вывода, пытаясь переключить файлы сбора данных
или уплотненные файлы в новый каталог. То же самое происходит,
когда требуется восстановление в случае, если в файловой системе
остается слишком мало свободного пространства. Бывают ситуации,
когда подсистема не в состоянии продолжить работу. Если запорчен
дисковый носитель или в файловой системе не осталось места, подсистема
прекращает работу и выдает сообщение об этом на системную
консоль. Любое условие аварийного прекращения приводит к выдаче
сообщения на консоль, с помощью которого можно определить
проблему. Если говорить вообще о системных проблемах, то симптомы
обычно не сводятся только к контролю. Одна из вероятных проблем,
которая может возникнуть при удалении и последующем восстановлении
файла параметров контроля, связана с дублированием создаваемых
сессий. При каждом включении контроля создается новая
сессия. Сессия определяется журнальным файлом и всеми уплотненными
файлами, сгенерированными за период контроля. Файлы снабжаются
уникальной меткой - номером сессии, чтобы их можно было
легко идентифицировать и использовать утилитами подсистемы, которым
нужен доступ к файлам; эти утилиты могут работать не с
именами файлов, а с номерами сессий. Если допускается оставлять
сессии в машине, а файл параметров модифицируется таким образом,
что номер сессии подсистемы сбрасывается, то в результате может
быть предпринята попытка создать файл контроля с тем же именем,
что и в предыдущей сессии. В таком случае старая сессия должна
быть занесена в архив и удалена с помощью программы интерфейса
до возобновления контроля.
Терминология контроля
Файл сбора данных контроля (audit collection file) - файл,
в который ведется запись драйвером устройства подсистемы контроля;
он содержит необработанные данные контроля, полученные из
всевозможных источников контроля в системе - системных вызовов,
надежных прикладных программ, авторизованных подсистем.
- 5-46 -
Уплотненный файл контроля (audit compaction file) - файл,
записываемый демоном контроля; он содержит буфера данных, считанных
с драйвера устройства контроля. Данные могут быть в уплотненном
или неуплотненном формате, в зависимости от опций,
выбранных при запуске сессии контроля.
Демон контроля (audit daemon) - демон-процесс, стартующий
при переходе системы в многопользовательское состояние. Он читает
контрольные записи с устройства подсистемы контроля, уплотняет
эти записи и записывает их в постоянный уплотненный файл для
последующей редукции. Демон также выступает в роли программы интерфейса,
которая позволяет незащищенным подсистемам заносить
контрольные записи в устройство контроля.
Сессия контроля (audit session) - период времени от включения
контроля до его выключения. В течение этого времени данные
контроля сохраняются в уплотненных файлах, куда ведет запись демон.
Каждая сессия снабжается уникальным номером, и каждый файл,
являющийся частью сессии, содержит этот уникальный идентификатор
в своем имени. В каждой сессии имеется главный файл, собирающий
информацию о сессии и имена файлов сессии для последующей редукции.
Подсистема контроля (audit subsystem) состоит из компонентов,
обеспечивающих надежный сервис контроля. Сюда входит драйвер
устройства контроля, механизм контроля ядра, демон контроля,
интерфейс Администратора контроля и программа редукции контроля.
Контрольный журнал (audit trail) - совокупность контрольных
записей для сессии контроля, которые можно редуцировать в отчет
о работе системы.
Редукция контроля (audit reduction) - преобразование необработанных
данных из контрольного журнала в выходные записи, содержащие
даты, идентификаторы пользователей, имена файлов и типы
событий. Выходная запись описывает контролируемое событие в читабельном
текстовом виде.
configaudit - авторизация ядра, которая позволяет устанавливать
параметры контроля для всех пользователей системы.
Маска управления событиями (event control mask) - маска,
определяемая и поддерживаемая для каждого пользователя в защищенной
базе данных паролей. Эта маска указывает, имеет ли пользовательская
маска событий приоритет по сравнению с системной
маской событий, принимаемой по умолчанию, при включении контроля.
Каждый установленный бит маски управления событиями определяет
приоритет маски диспозиции событий.
Маска диспозиции событий (event disposition mask) - определяемая
пользователем маска, применяемая в сочетании с маской управления
событиями для управления пользовательскими событиями
контроля. Если в пользовательской маске управления событиями установлен
какой-нибудь бит, то соответствующий бит маски диспозиции
событий будет определять, должно ли это событие контролиро-
Filesystems -"
независимо от значения системной маски событий, принимаемой по
умолчанию.
- 5-47 -
Тип события (event type) - классификация для каждой контрольной
записи. События в системе, связанные с секретностью,
классифицируются по определенным типам, которые можно использовать
для управления генерацией контроля и редукцией. Каждое системное
действие, успешное или неудачное, можно отнести к некоторому
типу события. Этот тип события затем будет определять
диспозицию записи.
Объект (object) - это то, на что воздействует субъект (например,
файлы, разделяемые сегменты памяти, семафоры, каналы связи,
очереди сообщений).
Пост-выборка (post-selection) - выборочное использование
собранных данных контроля. Пост-выборка включает сбор данных
контроля по всем событиям и пользователям, так что информация в
контрольном журнале оказывается максимально полной. Любое событие,
связанное с секретностью, в конце сессии попадет в уплотненные
файлы контрольного журнала.
Предварительная выборка (pre-selection) используется для
управления выборочной генерацией контрольных записей. Это дает
возможность определенным пользователям и событиям генерировать
контрольные записи, с отбрасыванием остальных записей. В результате
получается более компактный контрольный журнал, с меньшими
подробностями, чем при полном контроле.
Файлы выборки (selection files) генерируются через административный
интерфейс для управления выборочной редукцией
сессий контроля. Критерии выборки определяют отбор пользователей,
объектов и событий для выходных записей.
Субъект (subject) - активный элемент, выполняющий действия
с объектами, - например, процесс в системе, осуществляющий доступ
к файлам.
suspendaudit - авторизация ядра, приостанавливающая контроль.
Системная маска контроля (system audit mask) - системная
маска событий, принимаемая по умолчанию; используется для определения,
какие события подлежат контролю в случае, когда пользовательская
маска не имеет приоритета.
Пользовательская маска контроля (user audit mask) - общее
название масок управления событиями и диспозиции событий, которые
вместе с системной маской, принятой по умолчанию, управляют
генерацией контрольных записей для каждого процесса.
writeaudit - авторизация ядра, позволяющая заносить специальную
информацию в контрольный журнал.
- 5-48 -
СРЕДСТВА ЗАЩИТЫ ФАЙЛОВОЙ СИСТЕМЫ
В вашу систему включены важные возможности файловой системы,
которые расширяют средства защиты, имеющиеся в других системах
UNIX. Эти возможности значительно повышают безопасность системы.
Одна из таких возможностей - очистка битов SGID и SUID при
записи в файл - является пассивной в том смысле, что для своего
выполнения не требует никаких действий с вашей стороны, т.е. со
стороны Администратора системы. Другие возможности являются активными,
т.е. вы можете использовать их или не использовать по
своему усмотрению. К числу таких активных возможностей, описываемых
ниже, относится специальное использование sticky-бита в каталогах
и использование променов. В настоящем разделе также описано
импортирование файлов из других систем.
Очистка битов SUID/SGID и sticky-бита при записи
Операционная система обеспечивает очистку битов SUID, SGID
и sticky-бита для файлов, в которые производится запись. Очистка
выполняется для того, чтобы предотвратить замещение программы
SUID/SGID или программы, считающейся резидентной в памяти.
В следующем примере дважды демонстрируется очистка бита:
$ id
uid=76(blf) gid=11(guru)
$ ls -l myprogram
-rwsrwsrwt 1 root bin 10240 Jan 11 22:45 myprogram
$ cat sneakyprog " myprogram
$ ls -l myprogram
-rwxrwxrwx 1 root bin 10240 Mar 18 14:18 myprogram
$
$ ls -l anotherprog
-rws------ 1 blf guru 83706 Dec 15 1987 anotherprog
$ strip anotherprog
$ ls -l anotherprog
-rwx------ 1 blf guru 17500 Mar 18 14:19 anotherprog
$
Первый случай демонстрирует, что очистка бита происходит
при записи в файлы, принадлежащие другому пользователю. Второй
случай показывает, что очистка бита делается даже для файлов,
принадлежащих тому же пользователю. Следует иметь в виду, что
очистка происходит п
...Закладка в соц.сетях
