Правило запрета по записи является большим
упрощением некоторых реализаций БЛМ.
Так, некоторые описания включают более
детальное понятие типа доступа (например
такие, как добавление и выполнение). Помимо
этого многие модели БЛМ включают понятие
дискретной защиты с целью обеспечения
хорошо гранулированной защиты при сохранении
всех преимуществ БЛМ.
Несмотря на все достоинства, оказалось,
что при использовании БЛМ в контексте
практического проектирования и разработки
реальных компьютерных систем возникает
ряд технических вопросов. Данные вопросы
являются логическим следствием достоинства
БЛМ - ее простоты. Проблемы возникают
при рассмотрении вопросов построения
политик безопасности для конкретных
типов систем, то есть на менее абстрактном
уровне рассмотрения. При данном рассмотрении
системный компонент модели усложняется,
что может привести к неадекватности БЛМ
в ее классической форме. Как следствие,
в мире компьютерной безопасности ведется
широкая полемика по поводу применимости
БЛМ для построения безопасных систем.
Несмотря на достоинства модели
Белла–Лападула, при ее строгой реализации
в реальных АС возникает ряд проблем.
1. Завышение уровня
секретности, связанное с одноуровневой
природой объектов и правилом безопасности
по записи. Если субъект с высоким уровнем
доступа хочет записать что-то в объект
с низким уровнем секретности, то сначала
приходится повысить уровень секретности
объекта, а потом осуществлять запись.
Таким образом, даже один параграф, добавленный
в большой документ субъектом с высоким
уровнем доступа, повышает уровень секретности
всего этого документа. Если по ходу работы
изменения в документ вносят субъекты
со все более высоким уровнем доступа,
уровень секретности документа также
постоянно растет.
2. Запись вслепую.
Эта проблема возникает, когда субъект
производит операцию записи в объект с
более высоким уровнем безопасности, чем
его собственный. В этом случае, после
завершения операции записи, субъект не
сможет проверить правильность выполнения
записи при помощи контрольного чтения,
так как ему это запрещено в соответствии
с правилом безопасности по чтению.
3. Проблема удаленного
чтения-записи. В распределенных системах
при удаленном чтении файла создаются
два потока: от субъекта к объекту (запросы
на чтение, подтверждения, прочая служебная
информация) и от объекта к субъекту (сами
запрашиваемые данные). При этом, например,
если F(s)>F(o), то первый поток будет противоречить
свойству безопасности по записи. На практике
для решения этой проблемы надо разделять
служебные потоки (запросы, подтверждения)
и собственно передачу информации.
4. Доверенные субъекты.
Модель Белла–ЛаПадула не учитывает,
что в реальной системе, как правило, существуют
субъекты, действующие в интересах администратора,
а также системные процессы, например,
драйверы. Жесткое соблюдение правил запрета
чтения с верхнего уровня и запрета записи
на нижний уровень в ряде случаев делает
невозможной работу подобных процессов.
Соответственно, их также приходится выделять.
Мандатную модель целостности Биба часто
называют инверсией БЛМ. Это довольно
точное название, поскольку основные правила
этой модели просто переворачивают правила
БЛМ. Мы будем ссылаться на эти правила
как “нет чтения снизу” (NRD) и “нет записи
наверх” (NWU), и определим их в терминах
субъектов, объектов, и нового типа уровней
безопасности - уровней целостности, над
которыми может быть введено отношение
преобладания.
Правило NRD мандатной модели целостности
Биба определяется как запрет субъектам
на чтение информации из объекта с более
низким уровнем целостности. NRD является
полной противоположностью правила NRU
БЛМ, за исключением того, что здесь используются
уровни целостности, а не безопасности,
как в БЛМ. Правило NWU мандатной модели
целостности Биба определяется как запрет
субъектам на запись информации в объект
с более высоким уровнем целостности.
Это правило является полной противоположностью
правилу NWD БЛМ для случая уровней целостности,
а не безопасности.
Одним из преимуществ этой модели является
то, что она унаследовала многие важные
характеристики БЛМ, включая ее простоту
и интуитивность. Это значит, что проектировщики
реальных систем могут легко понять суть
этих правил и использовать их для принятия
решений при проектировании. Кроме того,
поскольку мандатная модель целостности
Биба, подобно БЛМ, основана на простой
иерархии, ее легко объяснить и изобразить
пользователям системы.
С другой стороны, модель представляет
собой очевидное противоречие с правилами
NRU и NWD. Это значит, что если необходимо
построить систему, которая предотвращает
угрозы как секретности, так и целостности,
то одновременное использование правил
моделей БЛМ и Биба может привести к ситуации,
в которой уровни безопасности и целостности
будут использоваться противоположными
способами.
Комбинирование моделей
безопасности
В реальных автоматизированных
системах редко встречаются системы защиты,
ориентированные исключительно на обеспечение
конфиденциальности или исключительно
на обеспечение целостности информации.
Как правило, система защиты должна сочетать
оба механизма – а значит, при ее построении
и анализе будет необходимым совместное
использование нескольких формальных
моделей безопасности.
- Списки управления
доступом
Unix-система права доступа файлов
определены режимами файлов:
8 битов задают, кто может
получить доступ к этому файлу,
и определяют режимы доступа.
Так как для прав доступа
применяются 9 битов, то это позволяет
создать три класса пользователей
(владелец, группа, остальные) и три
класса доступа (чтение, запись, выполнение).
Файловые системы ext2 и ext3 (обе
в настоящее время используется в Linux-системах)
поддерживают расширенные атрибуты файлов
(Extended Attributes, EA), позволяющие задать дополнительные
параметры в виде пары имя: значение для
каждого файла.
Расширенные атрибуты могут
употребляться для обслуживания прав
доступа для дополнительных групп пользователей,
что дает возможность создавать списки
управления доступом (ACL), ACL надо считать
расширением традиционной модели прав
доступа.
Управление доступом на основе ролей
(Role-based Access Control, RBAC)
В RBAC-системе каждому пользователю
назначены одна или несколько определенных
ролей (роль и UID - это не одно и то же), которые
он может реализовывать в системе, то есть
некоторые действия, которые разрешены
этому пользователю.
- Сравнительный анализ
различных типов систем
Операционные системы.
Flask
Операционная система Flux Advanced
Security Kernel, или как ее иначе называют FLASK —
это архитектура безопасности операционной системы, которая
обеспечивает гибкую поддержку политик
безопасности. Ранее Прототип архитектуры
FLASK был реализован в исследовательской
операционной системе Fluke.
В связи с этим, на наш взгляд,
интересно будет сказать несколько слов
об истории создания FLASK.
В 1992 и1993 годах исследователи Агентства национальной безопасности США и Secure Computing Corporation (SCC) работали
над реализацией Distributed Trusted Mach (DTMach), отпрыском
проектов TMach и Lock. DTMach интегрировал генерализацию
Type Enforcement (TE) — гибкого механизма доступа
в микроядро. Проект DTMach позже был продолжен в проекте Distributed Trusted Operating System (DTOS). В свою очередь, после внесения
усовершенствований проект DTOS дал рождение
прототипу, переданному университетам
для исследований.
Кроме того результатом проекта
DTOS стал отчёт — формальная спецификация
системы, включающий в себя: анализ политик
безопасности и их характеристик, научные
работы о безопасности, assurability и composability
techniques операционных систем, основанных
на микроядре.После завершения проекта
DTOS результаты его работы были использованы
в другом проекте NSA, SCC и университета
Юты (University of Utah) — проекте Flux, задачей которого было перенести
архитектуру безопасности DTOS в исследовательскую
операционную систему Fluke.
В процессе интеграции архитектуры
в Fluke, она была улучшена для поддержки
динамических политик безопасности. Эта улучшенная
архитектура была названа Flask. Некоторые
интерфейсы и компоненты Flask впоследствии
были перенесены из Fluke в OSKit.
Конечным итогом исследований
стала реализация архитектуры Flask для
операционной системы Linux в SELinux, выполненной
Агентством национальной безопасности
США, передавшим технологию многочисленным
сообществам пользователей и разработчиков.
Другими основными участниками проекта
SELinux являются: NAI Labs, Secure Computing Corporation иMITRE.
Некоторые компоненты и интерфейсы Flask были позже портированны
из прототипа Fluke в OSKit. Архитектура Flask была реализована
для операционной системы Linux (Security-Enhanced Linux, SELinux) для того, чтобы передать
технологию многочисленным сообществам
пользователей и разработчиков.
В настоящее время архитектура
Flask является основой для технологий реализации
систем принудительного контроля доступа,
таких как Security-Enhanced Linux (SELinux), OpenSolaris FMAC и TrustedBSD.
В завершение хочется еще раз
отметить, что в этой операционной система
первоначально была воплощена модель
мандатной политики безопасности.
Unix
История операционной системы
UNIX насчитывает уже более тридцати лет.
UNIX используются в военных и серьёзных
промышленных системах.
Модель безопасности UNIX довольно
проста. В основе её лежит дискреционный
механизм доступа - каждый объект в системе
имеет владельца, который и устанавливает
права доступа к объекту. Сами пользователи
в системе фигурируют в виде процессов
- программ, запущенных от их имени.
Так как в операционной системе
UNIX даже устройства представляются в виде
файлов, достаточно для каждого из них
хранить владельца и права на использование
этого файла другими пользователями системы.
В UNIX существует три основных
права доступа: чтение, запись и исполнение.
Если права чтения и записи очевидны и
понятны, то право исполнения трактуется
по-разному для разных типов файлов.
Для простых файлов оно определяет
возможность запуска содержащейся в нём
программы. В UNIX исполняемые файлы могут
иметь не только любое расширение, но и
содержимое.
Расположение файловой системы
UNUX
Linux
Оперционная система Linux унаследовала
от UNIX традиционную модель доступа. В отличие
от коммерческих систем, таких как Microsoft Windowsили Mac OS X, Linux не имеет географического
центра разработки. Нет и организации,
которая владела бы этой системой; нет
даже единого координационного центра.
Программы для Linux — результат
работы тысяч проектов. Некоторые из этих
проектов централизованы, некоторые сосредоточены
в фирмах. Многие проекты объединяют хакеров со всего света, которые знакомы
только по переписке. Создать свой проект
или присоединиться к уже существующему
может любой и, в случае успеха, результаты
работы станут известны миллионам пользователей.
Пользователи принимают участие
в тестировании свободных программ, общаются
с разработчиками напрямую, что позволяет
быстро находить и исправлять ошибки и
реализовывать новые возможности. Linux
является UNIX-совместимой, однако основывается
на собственном исходном коде.
Именно такая гибкая и динамичная
система разработки, невозможная для проектов
с закрытым кодом, определяет
исключительную экономическую эффективность
Linux.
Низкая стоимость свободных
разработок, отлаженные механизмы тестирования
и распространения, привлечение людей
из разных стран, обладающих разным видением
проблем, защита кода лицензией GPL — всё это стало причиной
успеха свободных программ.
Конечно, такая высокая эффективность
разработки не могла не заинтересовать
крупные фирмы, которые стали открывать
свои проекты.
Так появились Mozilla (Netscape, AOL), OpenOffice.org (ORACLE), свободный клон InterBase (Borland) — Firebird, SAP DB (SAP). IBM способствовала переносу Linux
на свои мейнфреймы.
С другой стороны, открытый код значительно снижает себестоимость
разработки закрытых систем для Linux и позволяет
снизить цену решения для пользователя.
Вот почему Linux стала платформой,
часто рекомендуемой для таких продуктов,
как СУБД Oracle, DB2, Informix, SyBase, SAP R3, Domino. Сообщество Linux поддерживает
связь посредством групп пользователей Linux.
В мае 2010 года семейство операционных
систем - на базе ядра Linux — третье по
популярности в мире на рынке настольных компьютеров.
Можно выделить несколько основных
областей, где нередко можно встретить
Linux:
Серверы, требующие высокого аптайма, Компьютеры нестандартной
архитектуры (например, суперкомпьютеры) —
из-за возможности быстрой адаптации ядра
операционной системы и большого количества
ПО под нестандартную архитектуру,
Системы военного назначения
(например, МСВС РФ) — по соображениям безопасности
, компьютеры, встроенные в различные устройства
(банкоматы, терминалы оплаты, мобильные
телефоны, маршрутизаторы, стиральные
машины и даже беспилотные военные аппараты) —
из-за широких возможностей по конфигурированию
Linux под задачу, выполняемую устройством,
а также отсутствия платы за каждое устройство.
Используемый в ней дискреционный
метод доступа предоставляет слишком
широкие возможности: любая программа,
запущенная от имени пользователя, обладает
всеми его правами.
Развитие операционных систем
не стоит на месте. Немалую роль в достижении
высокого уровня безопасности Linux сыграла
открытость исходных текстов и принципы
разработчиков, проповедующих использование
только открытых стандартов.
Вокруг Linux возникло множество
проектов, предоставляющих расширенные
возможности по управлению доступом.
SELinux
SELinux - это расширение
базовой модели безопасности операционной
системы Linux, добавляющее механизм мандатного
доступа.
С помощью SELinux можно
задать явные правила того, как субъекты
(пользователи и программы) могут обращаться
к объектам системы (файлы и устройства).