Защита файловой системы
Ясно, что наибольшее внимание в проблеме защиты операционной системы должно уделяться защите файловой системы.
Файловая система в UNIX имеет древовидную структуру. Том прямого доступа делится на несколько областей:
начальный загрузчик;
суперблок;
область индексных дескрипторов;
область файлов;
область, не используемая для файловой системы (например, область
для выгрузки процессов).
Суперблок состоит из следующих полей:
размер файловой системы;
количество свободных блоков в файловой системе;
заголовок списка свободных блоков, имеющихся в файловой системе;
номер следующего элемента в списке свободных блоков;
размер области индексов;
количество свободных индексов в файловой системе;
список свободных индексов в файловой системе;
следующий свободный индекс в списке свободных индексов;
заблокированные поля для списка свободных блоков и свободных
индексов; « флаг, показывающий, что в суперблок были внесены изменения.
При монтировании (команда mount) файловой системы суперблок записывается в оперативную память и переписывается обратно при раз-монтировании (команда unmount). Для того чтобы обеспечивалась согласованность с данными, хранящимися в файловой системе, ядро периодически (через 30 с) переписывает суперблок на диск (системный вызов sync, запускаемый из процесса update в SCO UNIX).
Каждый файл в системе UNIX имеет уникальный индекс. Индекс -это управляющий блок. В литературе он также называется индексным дескриптором, i-node или i-узлом. Индекс содержит информацию, необходимую любому процессу для того, чтобы обратиться к файлу, например права собственности на файл, права доступа к файлу, размер файла и расположение данных файла в файловой системе. Процессы обращаются к файлам, используя четко определенный набор системных вызовов и идентифицируя файл строкой символов, выступающих в качестве составного имени файла. Каждое составное имя однозначно определяет файл, благодаря чему ядро системы преобразует это имя в индекс файла.
Индексы существуют на диске в статической форме, и ядро считывает их в память прежде, чем начать с ними работать. Индексы содержат следующие поля.
1. Идентификатор владельца файла и идентификатор группы.
2. Тип файла. Файл может быть файлом обычного типа, каталогом, специальным файлом (соответствующим устройствам ввода-вывода символами или блоками, а также абстрактным файла канала, организующим обслуживание запросов в порядке поступления "первым пришел - первым вышел").
3. Права доступа к файлу. Права доступа к файлу разделены между индивидуальным владельцем, группой пользователей, в которую входит владелец файла, и всеми остальными. Суперпользователь (пользователь с именем root) имеет право доступа ко всем файлам в системе. Каждому классу пользователей выделены определенные права на чтение, запись и выполнение файла, которые устанавливаются индивидуально. Поскольку каталоги как файлы не могут быть исполнены, разрешение на исполнение в данном случае интерпретируется как право производить поиск в каталоге по имени файла, а право записи - как право создавать и уничтожать в нем файлы.
4. Временные сведения, характеризующие работу с файлом: время внесения последних изменений в файл, время последнего обращения к файлу, время внесения последних изменений в индекс.
5. Число указателей индекса, означающее количество имен файлов, ссылающихся на данный файл.
6. Таблицу адресов дисковых блоков, в которых располагается информация файла. Хотя пользователи трактуют информацию в файле как логический поток байтов, ядро располагает эти данные в несмежных дисковых блоках.
7. Размер файла в байтах.
Обратим внимание, что в индексе отсутствует составное имя файла, необходимое для доступа к файлу.
Содержимое файла меняется только тогда, когда в файл производится запись. Содержимое индекса меняется при изменении как содержимого файла, так и владельца файла, прав доступа и т.д. Изменение содержимого файла автоматически вызывает коррекцию индекса, однако коррекция индекса еще не означает изменение содержимого файла.
При открытии файла индекс копируется в память и записывается обратно на диск, когда последний процесс, использующий этот файл, закроет его. Копия индекса в памяти содержит кроме полей дискового индекса следующие поля.
1. Состояние индекса в памяти, отражающее:
• заблокирован ли индекс;
• ждет ли снятия блокировки с индекса какой-либо процесс;
• отличается ли представление индекса в памяти от своей дисковой копии в результате изменения содержимого индекса;
• отличается ли представление индекса в памяти от своей дисковой копии в результате изменения содержимого файла;
• находится ли указатель файла в начале.
2. Логический номер устройства файловой системы, содержащей файл.
3. Номер индекса. Так как индексы на диске хранятся в линейном массиве, ядро идентифицирует номер дискового индекса по его местопо-ложению в массиве. В дисковом индексе это поле не нужно.
4. Указатели других индексов в памяти.
5. Счетчик ссылок, соответствующий количеству активных (открытых) экземпляров файла.
Многие поля в копии индекса, с которой ядро работает в памяти, аналогичны полям в заголовке буфера, и управление индексами похоже на управление буферами. Индекс также блокируется, в результате чего другим процессам запрещается работа с ним. Эти процессы устанавливают в индексе специальный флаг, информирующий о том, что выполнение обратившихся к индексу процессов следует возобновить, как только блокировка будет снята. Установкой других флагов ядро отмечает расхождение между дисковым индексом и его копией в памяти. Когда ядру нужно будет записать изменения в файл или индекс, оно перепишет копию индекса из памяти на диск только после проверки этих флагов.
Каталоги (справочники) являются файлами, из которых строится иерархическая структура файловой системы. Они играют важную роль в превращении имени файла в номер индекса. Каталог - это файл, содержимым которого является набор записей, состоящих из номера индекса и имени файла, включенного в каталог. Составное имя - это строка символов, завершающаяся пустым символом и разделяемая наклонной чертой (Т) на несколько компонентов. Каждый компонент, кроме последнего, должен быть именем каталога, но последний компонент может быть именем файла, не являющегося каталогом. Имя корневого каталога - "/". В ОС UNIX длина каждого компонента определяется 14 символами. Таким образом, вместе с 2 байтами, отводимыми для номера индекса, размер записи каталога составляет, как правило, 16 байт.
Традиционно в файловых системах ОС UNIX за доступ ко всем типам файлов (файлы, справочники и специальные файлы) отвечают 9 бит, которые хранятся в i-узле. Первая группа из 3 бит определяет права доступа к файлу для его владельца, вторая - для членов группы владельца, третья - для всех остальных пользователей.
Например, права доступа "rwxr-xr-" к файлу означают, что владелец файла имеет полный доступ, члены группы имеют возможность чтения и выполнения, все остальные имеют возможность только читать данный файл. Для справочника установка бита выполнения "х" означает возможность поиска (извлечения) файлов из этого справочника.
Такая система защиты файлов существует достаточно давно и не вызывает нареканий. Действительно, для того чтобы вручную, т.е. не ис-
пользуя системные вызовы и команды, изменить права доступа к файлу, следует иметь доступ к области i-узлов. Для того чтобы иметь доступ к области i-узлов, следует изменить права доступа специального файла (например, /dev/root), биты доступа которого также хранятся в области i-узлов. Иными словами, если случайно или умышленно не испортить права доступа ко всем файлам системы, установленные по умолчанию (обычно правильно) при инсталляции, то можно с большой степенью вероятности гарантировать безопасность работы системы.
Согласно принципам построения ОС UNIX необходим еще четвертый-бит, определяющий права на выполнение исполняемого файла. Четвертый бит в самом общем случае интерпретируется как возможность смены идентификатора пользователя. Его смысловая нагрузка меняется в зависимости от того, в какой группе битов доступа он установлен. Если четвертый бит установлен в группе битов прав доступа владельца (setuid), то данная программа выполняется для любого пользователя с правами владельца этого файла.
В любой системе UNIX таких команд очень много. Тривиальный пример использования незарегистрированного файла с установленным битом setuid заключается в следующем:
• один раз, узнав пароль какого-либо пользователя, злоумышленник создает копию командного интерпретатора в своем домашнем справочнике или еще где-нибудь, чтобы его не узнали, например в глубоком дереве в /usr/tmp (заметим, что рекурсивная работа с деревом весьма ограничена по глубине, которая для SCO UNIX равна примерно 15);
• делает владельцем файла другого пользователя и его правами устанавливает бит setuid;
• до тех пор пока данный файл не будет уничтожен, злоумышленник будет пользоваться правами другого пользователя.
В этом примере очевидно, что если злоумышленник случайно один раз узнает пароль суперпользователя, то он будет обладать полностью его правами. Поэтому необходимо регулярно проверять все файловые системы на наличие незарегистрированных файлов с установленным битом setuid.
Если четвертый бит установлен в группе бит прав доступа членов группы (setgid), то данная программа выполняется для любого пользователя с правами членов группы этого файла.
Бит setgid в системах UNIX используется гораздо реже, чем бит setuid, однако все сказанное относительно возможных угроз при установке бита setuid справедливо для бита setgid. Если бит setgid установлен для справочника, то это означает, что для всех файлов, создаваемых пользователем в этом справочнике, групповой идентификатор будет установлен таким же, как у справочника.
Если четвертый бит установлен в группе битов прав доступа всех остальных пользователей (бит sticky), то это указывает операционной системе делать специальный текстовый образ выполняемого файла. На сегодняшний день для выполняемого файла бит sticky обычно не используется. Он используется только для справочников. Его установка для справочника означает, что пользователи не имеют права удалять или переименовывать файлы других пользователей в этом справочнике.
Это необходимо прежде всего для справочников /tmp и /usr/tmp, чтобы один пользователь случайно или специально не смог повредить работе другого пользователя. Следует напомнить, что самой распространенной ошибкой администратора является установка в переменную окружения PATH значения текущего справочника, что делается для удобства, чтобы не набирать перед каждой командой текущего справочника символы ".Г. Хуже всего, если это значение установлено в начале. Например, PATH=.:/bin:/usr/bin:/etc. В этом случае достаточно злоумышленнику поместить в справочник /tmp или /usr/tmp собственные образы наиболее распространенных команд (Is, ps и т.п.) - и последствия набора безобидной последовательности команд (например, cd /tmp; Is) будут трудно предсказуемы. Обычно по умолчанию в переменной окружения PATH текущий справочник не установлен. Аналогично плохо для системы могут закончиться попытки запуска неизвестных пользовательских программ из их домашних или общих справочников.
Бит sticky для справочника может установить только администратор. Очевидно, что он может и удалить файлы любого пользователя в этом справочнике. Для повышения надежности функционирования системы следует установить биты sticky для всех общих справочников.
Важной особенностью реализации системы защиты информации является очистка битов setuid, setgid и sticky для файлов, в которые производится запись. При этом очистка битов делается даже для файлов, если в них произведена запись владельца. Очистка перечисленных битов для справочников не производится.
Некоторые системы UNIX (например, Solaris) предоставляют дополнительные возможности по управлению правами доступа к файлам путем использования списков управления доступом (Access Control List). Данный механизм позволяет для каждого пользователя или для отдельной группы установить индивидуальные права доступа к заданному файлу. При этом списки доступа сохраняются всеми системными средствами копирования и архивирования. Нельзя сказать, что введение этого механизма принципиально улучшает защиту файлов. Тем не менее он вносит некоторую гибкость в процедуру формирования прав доступа к файлам.
Отдельно следует рассмотреть значение системной переменной umask. С ее помощью устанавливаются по умолчанию права доступа к файлу при его создании. Значение переменной umask устанавливает, какие биты будут маскироваться. Например, в SCO UNIX значение переменной umask по умолчанию установлено 022. Это означает, что для любого созданного файла по умолчанию будут установлены права доступа "rwxr-xr-х". Если значение переменной umask по каким-либо причинам будет изменено, то это может привести к непредсказуемым последствиям. В силу этого каждому пользователю необходимо явным образом прописать значение переменной umask в стартовом файле (.profile или .cshrc или т.п.).
В данном пособии не рассматриваются возможности закрытия файлов командой crypt, реализующей Data Encryption Standard (DES), поскольку данная системная команда в Россию не поставляется.
Необходимо подчеркнуть важность правильной установки прав доступа к специальным файлам. При этом надо помнить, что для одного и того же физического устройства могут существовать несколько специальных файлов (в зависимости от способа доступа). Например, /dev/root и /dev/rroot.
Следует обратить внимание на обеспечение режима защиты информации при импортировании данных из других систем. В самом общем случае архивные программы сбрасывают режимы доступа к файлам, которые могут повлиять на безопасность системы. Тем не менее количество версий архивных программ и их реализаций в различных системах UNIX весьма значительно. Так, ряд версий команды tar поддерживает опции, при которых не изменяется принадлежность файла владельцу и группе. Некоторые системы UNIX позволяют копировать специальные файлы с помощью команды tar, а некоторые не позволяют. С особым вниманием следует пользоваться командой cpio, поскольку с ее помощью можно сделать копии файлов, сохраняя все биты (setuid, setgid и sticky) и права доступа к файлам.
При монтировании файловых систем, созданных или обрабатывавшихся на других системах, могут возникнуть те же проблемы, что и для импортированных файлов. Для файловых систем имеются еще и дополнительные проблемы. Первая из них - файловая система, перенесенная с другой системы, может быть испорчена. Попутно заметим, что логические ошибки в файловой системе могут быть исправлены командой fsck перед монтированием. Гораздо хуже ОС UNIX относится к физическим сбоям на дисках. В обоих случаях монтирование дефектной файловой системы может привести систему к фатальному сбою, вызвать дальнейшее повреждение данных в импортированной файловой системе или повреждение других файловых систем из-за побочных эффектов.
Вторая проблема с импортированными файловыми системами может возникнуть из-за установленных прав доступа к файлам и справочникам, которые могут быть недопустимы для вашей системы. В этом случае для выявления установок различных битов (setuid, setgid, sticky) можно воспользоваться соответствующей командой (например, ncheck для SCO). Для поиска неправильных установок для файлов владельцев и групп в импортированной файловой системе можно предложить только ручной просмотр.
Контроль целостности системы
Известно, что стоимость восстановления системы выше стоимости ее сопровождения. В задачи сопровождения ОС входит, в частности, контроль целостности системы. В ОС UNIX контроль целостности системы выполняется рядом команд. Например, для контроля и поддержки целостности SCO UNIX основной перечень команд системы следующий: integrity, authck, fixmog, cps, tcbck, smmck, authckrc, fsck. Практика показывает, что данный набор команд является достаточно полным.
Стандартная последовательность действий после возникновения сбоя в системе или каких-либо других отклонений следующая:
• проверка файловой системы;
• составление контрольного отчета;
• проверка базы данных аутентификации;
• проверка разрешений для системных файлов.
Следует отметить, что системные средства восстановления целостности системы работают до определенного предела. Авторами был проведен следующий эксперимент для SCO UNIX Release 5.0:
• всем файлам системы был назначен владелец root;
• у всех файлов системы были установлены права доступа со значением по умолчанию системной переменной umask.
В результате этих действий системными средствами не удалось восстановить нормальные права доступа и владельцев файлов. Такой эксперимент имеет жизненную основу, например размножение системы на другие компьютеры по сети. Поэтому единственным способом дублирования системы на другие компьютеры следует считать использование команды cpio. Также следует отметить, что в SCO Release 3.2 и Release 5.0 права доступа и владельцы некоторых файлов по умолчанию не соответствуют базе данных контроля целостности системы. Авторами не исследовались вопросы влияния этих несоответствий на безопасность и целостность работы системы.
3. Средства аудита
Будем считать, что действие контролируется, если можно определить реального пользователя, который его осуществил. Концептуально при построении ОС UNIX некоторые действия нельзя контролировать на уровне действий реального пользователя. Например, пользовательские бюджеты, такие как Ip, cron или uucp, используются анонимно, и их действия можно обнаружить только по изменениям в системной информации.
Система контроля регистрирует события в операционной системе, связанные с защитой информации, записывая их в контрольный журнал. В контрольных журналах возможна фиксация проникновения в систему и неправильного использования ресурсов. Контроль позволяет просматривать собранные данные для изучения видов доступа к объектам и наблюдения за действиями отдельных пользователей и их процессов. Попытки нарушения защиты и механизмов авторизации контролируются. Использование системы контроля дает высокую степень гарантии обнаружения попыток обойти механизмы обеспечения безопасности. Поскольку события, связанные с защитой информации, контролируются и учитываются вплоть до выявления конкретного пользователя, система контроля служит сдерживающим средством для пользователей, пытающихся некорректно использовать систему.
В соответствии с требованиями по надежности операционная система должна создавать, поддерживать и защищать журнал регистрационной информации, относящейся к доступу к объектам, контролируемым системой. При этом должна быть возможность регистрации следующих событий:
• использования механизма идентификации и аутентификации;
• внесения объектов в адресное пространство пользователя (например, открытие файла);
• удаления объектов;
• действий администраторов;
• других событий, затрагивающих информационную безопасность.
Каждая регистрационная запись должна включать следующие поля:
• дата и время события;
• идентификатор пользователя;
• тип события;
• результат действия.
Для событий идентификации и аутентификации регистрируется также идентификатор устройства. Для действий с объектами регистрируются имена объектов.
Типы контролируемых событий, поддерживаемые в SCO Release 5.0, приведены в табл. 1.
Система контроля использует системные вызовы и утилиты для классификации действий пользователей, подразделяя их на события различного типа. Например, при возникновении события типа "DAC Denials" (отказ доступа при реализации механизма избирательного разграничения доступа) регистрируются попытки такого использования объекта, которые не допускаются разрешениями для этого объекта. Иными словами, если пользовательский процесс пытается писать в файл с доступом "только для чтения", то возникает событие типа "DAC Denials". Если просмотреть контрольный журнал, то легко можно увидеть повторяющиеся попытки доступа к файлам, на которые не получены разрешения.
Существенно повышает эффективность контроля наличие регистрационного идентификатора пользователя (LUID). После прохождения пользователем процедур идентификации и аутентификации, т.е. непосредственного входа в систему, каждому процессу, создаваемому пользователем, присваивается регистрационный идентификатор пользователя. Данный идентификатор сохраняется, несмотря на переходы от одного пользовательского бюджета к другому, с помощью таких команд, как su.
Каждая контрольная запись, генерируемая системой контроля, содержит для каждого процесса регистрационный идентификатор наряду с эффективным и реальным идентификаторами пользователя и группы. Таким образом, оказывается возможным учет действий пользователя.
Отдельно следует рассмотреть реализацию механизма контроля для работы в режиме ядра. Данный механизм генерирует контрольные записи по результатам выполнения пользовательских процессов с помощью системных вызовов ядра. Каждый системный вызов ядра содержит строку в таблице, в которой указывается связь системного вызова с контролем защиты информации и тип события, которому он соответствует.
Таблица 1
Тип | Содержание |
1. Startup/Shutdown | Старт (загрузка)/выгрузка системы |
2. Login/Logout | Успешный вход и выход из системы |
3. Process Create/Delete | Создание/уничтожение процесса |
4. Make Object Available | Сделать объект доступным (открыть файл, открыть сообщения, открыть семафор, монтировать файловую систему и т.п.) |
5. Map Object to Subject | Отобразить объект в субъект (выполнение программы) |
6. Object Modification | Модификация объекта (запись в файл и т.п.) |
7. Make Object Unavailable | Сделать объект недоступным (закрыть файл, закрыть сообщение, закрыть семафор, размонтировать файловую систему и т.п.) |
8. Object Creation | Создание объекта (создание файла/сообщения/семафора и т.п.) |
9. Object Deletion | Удаление объекта (удаление файла/сообщения/семафора и т.п.) |
10. DAC Changes | Изменение разграничения доступа (изменение доступа к файлу, сообщению, семафору, изменение владельца и т.п.) |
11. DAC Denials | Отказ доступа (отсутствие прав доступа к какому-либо объекту) |
12. Admin/Operator Actions | Действия (команды) системных администраторов и операторов |
13. Insufficient Authorization | Процессы, которые пытаются превысить свои полномочия |
14. Resource Denials | Отказы в ресурсах (отсутствие необходимых файлов, превышение размеров памяти и т.п.) |
15. IPC Functions | Посыпка сигналов и сообщений процессам |
16. Process Modifications | Модификации процесса (изменение эффективного идентификатора процесса, текущего справочника процесса и т.п.) |
17. Audit Subsystem Events | События системы контроля (разрешение/запрещение системного контроля и модификация событий контроля) |
18. Database Events | События базы данных (изменение данных безопасности системы и их целостности) |
19. Subsystem Events | События подсистемы (использование защищенных подсистем) |
20. Use of Authorization | Использование привилегий (контроль действий с использованием различных привилегий) |
Кроме того, используется таблица кодов ошибок, позволяющая классифицировать системные вызовы как конкретные события, связанные с защитой информации.
Например, системный вызов open классифицируется как событие "Сделать объект доступным". Если пользователь выполняет системный вызов open для файла /unix и данный системный вызов завершается ус пешно, то генерируется контрольная запись об этом событии. Однако если системный вызов open заканчивается неудачно в силу того, что пользователь запросил в системном вызове доступ на запись файла /unix, не имея разрешения, то это действие классифицируется как событие "Отказ доступа" для данного пользователя и объекта /unix. Следовательно, системный вызов можно отобразить в несколько типов событий, в зависимости от объекта, к которому осуществляется доступ, и (или) результата вызова.
Некоторые системные вызовы не имеют отношения к защите информации. Например, системный вызов getpid получает идентификатор процесса и не определяет никакого события, связанного с защитой информации. Таким образом, данный системный вызов не подлежит контролю.
Механизм контроля ядра выдает внутренний вызов в драйвер устройства для занесения записи в контрольный журнал. Отметим, что информацию контроля система записывает непосредственно на диск, не дожидаясь синхронизации суперблоков в оперативной памяти и на диске. Этим достигается полная защита от разрушения информации контроля. Однако следует иметь в виду, что при включении всех событий контроля и при активной работе пользователей объем записываемой информации может достигать нескольких мегабайтов на одного пользователя в час. Поэтому контроль следует рассматривать не как превентивную меру, а как меру пресечения.
Дата добавления: 2015-09-07; просмотров: 2927;