Защита информации в виртуальной файловой системе. Сразу сделаю замечание – следует различать виртуальную файловую систему и механизмы виртуализации памяти. В последнем случае речь идёт о расширении размеров памяти, доступной задачам, за счет использования памяти на жёстких дисках и специальной организации дескрипторных таблиц.
Виртуальная файловая система – это одно из множества преимуществ *nix перед другими операционными системами. В Linux, благодаря особой структуре ядра, похожей на детский конструктор, разработка поддержки нового оборудования не только удивительно проста, но и совсем незначительно увеличивает код ОС.
Ключевая идея VFS (Virtual File System) заключена в том, что к любой файловой системе применима обобщённая модель файла, как набора некоторых данных. Не важно на самом деле, имеете ли вы дело с принтером, с файлом на дискете или удалённом SMB-ресурсе, с данными вы всегда выполняете одни и те же действия: создание, чтение, запись, удаление и др. Например, когда вы распечатываете, происходит «запись данных в принтер».
Когда мы имеем дело с великим разнообразием различных файловых систем, нас опять спасает модульность ядра Linux. Для реализации механизмов виртуальной файловой системы, как и в случае с модулем защиты, используются указатели на функции. Системные вызовы используют указатели на структуры в памяти, ассоциированные с данным физическим объектом, для вызова процедур обработки в соответствии с данной файловой системой. Дело в том, что каждая такая структура содержит список указателей, которые переопределяются новыми значениями при инициализации структуры. Поэтому при file->f_op->read (…..) в зависимости от файловой системы в итоге выполнится функция, учитывающая специфику данной файловой системы. Что это даёт? Разработчик вместо того, чтобы переписывать всё ядро, пишет специальный модуль (драйвер), в котором переопределяет данные структур виртуальной файловой системы. Второе преимущество в том, что разрабатывать драйвер и писать ядро защиты ОС могут два абсолютно не связанных друг с другом человека. Разработчик системы безопасности использует унифицированные вызовы процедур работы с «виртуальными файлами».
Механизм LSM полностью покрывает виртуальную файловую систему, используя основные типы хранимых её данных: супер-блоки (super_block), индексные дескрипторы (inode), файловые объекты (file), каталоговые записи (dentry).
Суперблоки нужны для хранения информации, касающейся примонтированной файловой системы. Индексные дескрипторы хранят данные о конкретном файле или системном объекте. Каждый индексный дескриптор имеет свой уникальный индекс, который однозначно идентифицирует файл в данной файловой системе. Файловые объекты нужны для хранения информации о взаимодействии некоторого процесса с некоторым файлом. В разных файловых системах механизм каталогов организован по-разному. Факт того, что данный системный объект включен в данную директорию, отражается в закреплённой за данным объектом каталогой записи.
Для контроля доступа к этой информации используются процедуры обработки групп security_sb, security_inode и security_file. Структуры super_block, inode и file имеют поля-указатели на данные, касающиеся защиты информации: s_security, i_security и f_security соответственно. Функции для работы с этими указателями аналогичны случаю с полем security в структуре task_struct. В каждой из этих групп имеются функции инициализации и уничтожения меток безопасности, а также функции для контроля доступа к данным объектам.
Теперь вам не составит труда запретить даже пользователю root монтирование (отмонтирование) файловых систем, создание (редактирование, удаление) определённых файлов и так далее. Для более гибкого управления доступом к ресурсам нам понадобятся знания теоретических моделей защиты информации, а также некоторые идеи по реализации механизмов авторизованных (контролируемых) переводов нашей из одних состояний в другие.
Формальные модели защиты информации. Рассмотрим формальные модели «приземлено», научно популярно, «галопом по европам». Введем понятие объекта, как некоторой универсальной абстрактной модели любого элемента реальной системы (файла, процесса, пользователя, ресурса и так далее). Каждому объекту однозначно ставится в соответствие некоторая метка безопасности. Под меткой безопасности будем понимать группу данных, однотипную для всех объектов системы. Любой объект должен иметь одну из сущностей: активную или пассивную. Объект с активной сущностью может производить действия над объектами с пассивной сущностью.
Различают механизмы дискреционного (DAC) и принудительного (MAC) управления доступом к объектам. Разрешение производить субъектом то или иное действие над объектом называется правом, а любое действие над объектом (в том числе и смена прав), переводящее систему в некоторое новое состояние, называется переходом. Если субъект имеет право изменять права доступа к объекту, он называется владельцем данного объекта. У одного и того же объекта в данной терминологии может быть несколько владельцев. Дискреционное управление доступом позволяет владельцам определять права на доступ к принадлежащим им объектам. Но есть случаи, когда требуется строго подчинить все переходы в системе некоторой группе правил, которые не смогут изменять ни какие субъекты – для этого предназначено принудительное (мандатное) управление доступом. Данная группа правил устанавливает концепцию взаимоотношений между различными типами объектов системы. Концепция НЕ ИЗМЕННА. В рамках концепции можно указать принадлежность тех или иных объектов тем или иным типам. Считается, что в крутой системе безопасности должны быть реализованы оба подхода. То есть система должна иметь централизованное мандатное управление доступом, а конкретные субъекты в рамках соблюдения мандатных механизмов должны иметь возможность управлять доступом к своим объектам.
Вообще существует три типа угроз информации: нарушение конфиденциальности, нарушение целостности и нарушение доступности информации.
Если безопасность некоторого начального состояния вашей системы доказана формально и не существует способа перевести систему в небезопасное состояние, то такая система будет называться защищённой. Но на практике в таком случае мы получим некоторую жесткую, не поддающуюся перенастройке систему. Для решения этой проблемы вводятся понятия авторизованного перехода и авторизованного субъекта. Авторизованным субъектом называется субъект, который может менять типы некоторых объектов. Полномочия авторизованных субъектов задаются концептуально и не могут быть изменены. Любые изменения в системе, касающиеся безопасности, должны быть согласованы с авторизованным субъектами, наделенным соответствующими полномочиями.
Для реализации дискретной модели часто используют списки управления доступом (Access Control List), или как их называют ACL-списки. ACL-списки можно представить двумя путями: 1 – хранить для некоторого объекта список прав доступа тех или иных субъектов к данному объекту, 2 – для каждого субъекта определить список доступных объектов и права доступа.
В моделях принудительного управления доступом вводят понятия информационного потока, как направления движения информации в системе. Грубо выражаясь, например, если субъект «записывает» в объект, то информация движется от субъекта к объекту. При чтении наоборот. За каждым объектом закрепляется некоторый уровень секретности. Модели MAC относительно уровней секретности устанавливают разрешенные направления потоков информации в системе. В модели Белла-Ла Падулы любой поток информации имеет два свойства: свойство секретности – субъект может читать объекты своего уровня секретности или менее секретных уровней, и свойство * - субъект может писать только в объекты своего или более секретного уровня. Эти правила гарантируют защиту конфиденциальности информации в системе. В обратной модели Биба любой поток информации имеет точно противоположные свойства: свойство целостности – субъект может писать только в объекты своего уровня или менее секретных уровней, свойство * - субъект может читать объекты своего уровня секретности или более секретных уровней. Эти правила гарантируют защиту целостности данных в системе.
При соблюдении всего этого в реализации вашей системы безопасности, вы теоретически получите защищённую систему.
Реализация абстрактной категории авторизованного субъекта. В реальных системах безопасности авторизованный субъект может иметь название администратор (офицер) безопасности, а также офицер защиты данных – это две разные категории, но на этом пока замарачиваться не будем. Заметим, что системный администратор root в Linux в общем случае ни в коем случае не является ни офицером безопасности, ни офицером защиты данных.
Для того, чтобы root не мог выполнять функции авторизованного субъекта, должна быть предусмотрены специальные механизмы защиты системных вызовов ОС, выполняющих перевод системы из одного состояния в другое. То есть для выполнения каждого важного системного вызова, пользователь должен проходить защищённую авторизацию.
Например, модуль SIDSCORE (Secure Intrusion Detection System CORE) системы безопасности SIDS для выполнения каждого «важного» системного вызова в качестве параметра необходимо передать некоторый одноразовый ключ фиксированной длины, который был получен на выходе предшествующего системного вызова. Единственный «важный» вызов, не требующий ключа – это вызов для авторизации администратора безопасности, но он требует от вызывающего процесса аутентифицирующую информацию, то есть пароль. Этот вызов в случае успешной аутентификации возвращает начальный ключ, полученный с генератора случайных чисел с прибавлением особым образом системного времени в тактах процессора. Далее, как уже было сказано, ключ используется в последующем системном вызове, который в свою очередь генерирует новый ключ. «Сессия» администратора безопасности заканчивается вызовом окончания сессии, который подчищает память.
Пока все. Теперь вам по плечу написать собственный RSBAC или SELinux. По всем вопросам обращайтесь к автору по электронной почте:
walkid@yandex.ru.
