Содержание к диссертации
Введение
1 Средства и методы обеспечения информационной безопасности 10
1.1 Общие положения 10
1.2 Законодательный уровень 11
1.3 Административный уровень 12
1.4 Операционный уровень 15
1.4.1 Управление персоналом 15
1.4.2 Физическая защита 16
1.4.3 Поддержание работоспособности 17
1.4.4 Реакция на нарушения режима безопасности . 18
1.4.5 Планирование восстановительных работ 19
1.5 Программно-технические меры 20
1.5.1 Идентификация и аутентификация 21
1.5.2 Управление доступом 23
1.5.3 Протоколирование и аудит 24
1.5.4 Криптография 30
1.5.5 Экранирование 31
1.5.6 Связь программно-технических регуляторов 31
1.6 Выводы 32
2 Математические модели безопасных систем 33
2.1 Введение 33
2.2 Обобщение модели невлияния на вероятностные автоматы 34
2.2.1 Введение 34
2.2.2 Основные понятия и результаты 34
2.2.3 Вспомогательные утверждения 38
2.2.4 Доказательство теорем 39
2.2.5 Заключение 40
2.3 Оценка интегральной загруженности 40
2.3.1 Введение 40
2.3.2 Основные понятия и результаты 41
2.3.3 Вспомогательные утверждения 42
2.3.4 Доказательство теорем 44
2.3.5 Заключение 45
3 Реализация сервисов безопасности на основе встраиваемых модулей 47
3.1 Введение 47
3.2 Необходимость разделения приложений и сервисов безопасности 47
3.3 Встраиваемые модули и поддерживающая их инфраструктура 49
3.4 Встраиваемые модули аутентификации и их анализ . 51
3.5 Встраиваемые неинтерактивные модули аутентификации . 52
3.6 Функционально полный набор встраиваемых неинтерактивных модулей аутентификации 56
3.7 PNIAM-приложения 59
3.8 Выводы 61
4 Реализация многоуровневой политики безопасности в ОС Linux 62
4.1 Введение 62
4.2 Многоуровневая политика безопасности 62
4.3 Требования к операционным системам, реализующим многоуровневую политику безопасности 63
4.4 Основные проектные решения 66
4.5 Авторизация пользователей 68
4.6 Управление доступом к файлам 69
4.7 Процессы и их взаимодействие 73
4.8 Управление межсетевым доступом 76
4.9 Дополнительные средства администрирования 77
4.10 Выводы 77
Заключение 79
Литература 81
- Реакция на нарушения режима безопасности
- Обобщение модели невлияния на вероятностные автоматы
- Необходимость разделения приложений и сервисов безопасности
- Требования к операционным системам, реализующим многоуровневую политику безопасности
Введение к работе
Актуальность темы
Информационная (компьютерная) безопасность (ИБ) - ветвь информационных технологий, развивающаяся исключительно быстрыми темпами. Важность этой ветви в последние годы стала общепризнанной, что объясняется двумя основными причинами:
ценностью накопленных информационных ресурсов;
критической зависимостью от информационных технологий.
Проблематика ИБ не только важна, но и сложна. Свидетельством сложности является параллельный, весьма быстрый рост затрат на защитные мероприятия и количества нарушений ИБ в сочетании с ростом среднего ущерба от каждого нарушения, что также подчеркивает важность ИВ. Выпускается и используется все больше средств обеспечения ИБ, но большинство из них оказывается слабыми, содержащими уязвимости в спецификациях, архитектуре и/или реализации.
Средство обеспечения ИБ может быть надежным, только если его проект и реализация основаны на математических моделях, адекватно описьшающих сложные современные информационные системы (ИС) и содержащих достаточные условия гарантированной безопасности, допускающих практическую проверку. Принятые в настоящее время модели безопасных систем этим требованиям не удовлетворяют, оказываясь чересчур громоздкими. Из этого следует актуальность проблемы разработки новых моделей безопасности, что важно как в теоретическом, так и в практическом плане.
В современных условиях на первый план вышел такой аспект ИБ, как доступность. Большинство атак на ИС являются именно атаками на доступность; перерывы в доступности приводят к наибольшему ущербу. В
то же время, традиционные модели безопасности ориентированы в первую очередь на обеспечение конфиденциальности и целостности. Следовательно, актуальной является проблема создания математических моделей, ориентированных на доступность.
Наряду с математическими основами важнейшую роль играет архитектурная безопасность. Современные ИС уязвимы потому, что сложны, в них смешиваются прикладная функциональность и сервисы безопасности, нарушается принцип концептуальной экономии. Это делает актуальной проблему развития архитектурных подходов, обеспечивающих минимизацию числа и сложности связей между прикладными компонентами и модулями безопасности, упрощение интерфейсов и протоколов взаимодействия между ними.
Операционные системы (ОС) - фундамент современных ИС. От уровня безопасности, который ОС обеспечивают, зависит безопасность системы в целом. Для многих категорий информационных систем, как военных, так и гражданских, необходимы ОС, удовлетворяющие повышенным требованиям к безопасности, что делает актуальной практическую реализацию в них передовых архитектурных принципов обеспечения безопасности.
Все это свидетельствует о необходимости проведения новых исследований, развития более строгого подхода к проблемам ИБ, сочетающего построение моделей доказательно безопасных систем, применимых к современным распределенным ИС, и практических разработок на этой базе.
Цели диссертационной работы
Основная цель диссертационной работы состояла в исследовании, развитии и применении подхода к обеспечению информационной безопасности, предусматривающего построение математических моделей безопасных систем, обеспечение архитектурной безопасности и практическую реализацию развитых теоретических основ.
В диссертационной работе решались следующие задачи:
проведение анализа комплексного подхода к обеспечению информационной безопасности, классификация его составляющих, существующих средств и методов;
построение вероятностной модели гарантированно защищенной системы, а также вероятностной графовой модели распределенных
систем;
исследование проблемы архитектурной безопасности в сочетании с разделением приложений и сервисов безопасности, минимизацией числа компонентов, упрощением протокола их взаимодействия;
определение основных принципов, проектных и программных решений, необходимых для полномасштабной реализации в ОС класса Unix многоуровневой политики безопасности;
реализация функционально полного набора встраиваемых модулей безопасности, приложений, модификаций ядра ОС класса Unix.
Научная новизна
В диссертационной работе построена новая вероятностная модель гарантированно защищенной системы и новая вероятностная графовая модель распределенной системы. Для вероятностной модели гарантированно защищенной системы получены легко проверяемые достаточные условия безопасности.
Для вероятностной графовой модели распределенной системы получены оценки как необходимого, так и достаточного числа ребер для построения состоятельной оценки совокупного числа ребер.
В рамках развития концепции встраиваемых модулей безопасности предложено новое понятие встраиваемых неинтерактивных модулей аутентификации с простым и безопасным протоколом взаимодействия с приложениями и централизованным назначением полномочий.
Предложен набор привилегий доверенных субъектов в ОС с поддержкой многоуровневой политики безопасности, обладающий свойством минимальности.
Практическая ценность
В рамках диссертационной работы реализован функционально полный набор встраиваемых неинтерактивных модулей аутентификации (PNIAM) с поддержкой средств авторизации, протоколирования и смены аутентификационных токенов. Реализовано значительное число PNIAM-приложений, таких как login, passwd, ftp-frontend, Xserver и других.
Спроектированы и реализованы изменения ядра ОС Linux, обеспечивающие полномасштабную поддержку многоуровневой политики безопасности. Создана практически полностью автоматизированная система инсталляции ОС Linux с дополнительными механизмами безопасности.
Перечисленные практические результаты используются в ядре сети MSUNet Московского государственного университета им. М.В. Ломоносова, в подразделениях Московского государственного университета им. М.В. Ломоносова, на суперкомпьютерах российско-белорусского проекта "СКИФ".
Апробация
Основные положения диссертационной работы докладывались на Всероссийской научно-методической конференции "Телематика'99" (Санкт-Петербург, 1999), на Всероссийской научной конференции "Научный сервис в сети ИНТЕРНЕТ" (Новороссийск, 2001), на Международной научно-методической конференции "Новые информационные технологии в университетском образовании"(Кемерово, 2002), на XIII Международной конференции "ПРОБЛЕМЫ ТЕОРЕТИЧЕСКОЙ КИБЕРНЕТИКИ" (Казань, 2002), на семинаре "Современные сетевые техноло-гии"(МГУ, 2002).
Публикации
По теме диссертации опубликовано 15 печатных работ [7], [11], [12], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [72].
Объем и структура работы
Диссертация состоит из введения, четырех глав, заключения и списка литературы.
Первая глава представляет собой исследование комплексного подхода к обеспечению информационной безопасности с классификацией его составляющих и анализом существующих средств и методов.
Вторая глава содержит изложение теоретических результатов, относящихся к проблемам гарантированной безопасности и анализа сетевых потоков данных. В ней построены вероятностные модели гарантированно защищенной системы и распределенной системы.
Реакция на нарушения режима безопасности
При нарушениях режима безопасности важно вовремя эти нарушения заметить и оперативно на них прореагировать, чтобы минимизировать потери. Две основных компоненты реакции - блокирование нарушителя и уменьшение наносимого вреда и недопущение повторных нарушений. Реакция должна быть продумана заранее, чтобы действия оказались скоординированными и оперативными. Из произошедших нарушений необходимо извлекать уроки - обнаруженные уязвимости должны устраняться, виновные сотрудники - наказываться, и т.п. [25]. Ни одна организация не застрахована от аварий, вызванных как естественными причинами, так и чьей-то халатностью или злым умыслом. В то же время существуют критически важные функции, реализация которых должна быть непрерьгоной. Планирование восстановительных работ позволяет подготовиться к авариям, уменьшить вред от них и сохранить функционирование хотя бы в минимальном объеме. Можно выделить следующие этапы планирования восстановительных работ: - выявление критически важных функций, установление приоритетов; - идентификация ресурсов, необходимых для выполнения критически важных функций; - определение перечня возможных аварий; - разработка стратегии восстановительных работ; - подготовка к реализации выбранной стратегии; - проверка стратегии. Идентифицируя ресурсы, необходимые для выполнения критически важных функций, следует помнить, что многие из них имеют некомпьютерный характер. Критичные ресурсы обычно относят к одной из следующих категорий: - персонал; - информационная инфраструктура; - физическая инфраструктура.
Необходимо учитывать, что при переходе на резервные системы аппаратная платформа может сменится, поэтому следует рассмотреть вопрос совместимости. Проверку стратегии лучше осуществлять не путем организации тестовых аварий, а путем внимательного анализа плана восстановительных работ специалистами [25]. Программно-технические меры - последний и самый важный рубеж обороны. Как показывает статистика, основной ущерб наносят действия легальных пользователей, противостоять которым операционные регуляторы не в состоянии. Некомпетентность, неаккуратность при выполнении служебных обязанностей, злой умысел - только программно-технические меры позволяют с ними бороться. На программно-техническом уровне важнейшая роль принадлежит архитектурной безопасности. Есть общие принципы, в случае нарушения которых отдельные удачные разработки не смогут обеспечить надежную защиту. В число этих принципов входят: - непрерывность защиты в пространстве и времени; - эшелонированность обороны; - разнообразие защитных средств; - укрепление слабого звена; - следование признанным стандартам, использование апробированных решений; - иерархическая организация с небольшим числом сущностей на каждом уровне; - определение периметра безопасности.
Пример удачной реализации принципов архитектурной безопасности - концепция тонкого клиента (см., например, [2]). Концепция тонкого клиента является возрождением в сетевой среде идеи многопользовательского доступа к центральной ЭВМ. У тонких клиентов нет собственной долговременной памяти, они обеспечивают только ввод и отображение информации и, возможно, предоставляют вычислительные ресурсы. Применение тонких клиентов существенно облегчает и удешевляет сопровождение пользовательских рабочих мест, защиту пользовательской информации, контроль деятельности пользователей. Выделим основные классы программно-технических мер: - идентификация и аутентификация; - управление доступом; - протоколирование и аудит; - криптография; - экранирование. В работе [8], помимо перечисленных, рассматриваются дополнительные сервисы безопасности: - туннелирование; - контроль защищенности; - обнаружение и нейтрализация отказов; - оперативное восстановление; - управление, анализируется их место при реализации эшелонированной обороны. Детальное описание этих сервисов, однако, выходит за рамки настоящей работы. Идентификацию и аутентификацию можно считать основой программно-технических мер, поскольку остальные сервисы работают с именованными субъектами. Идентификация позволяет субъекту назвать себя; аутентификация позволяет доказать подлинность идентификатора. Субъект может доказать свою подлинность, предъявив одну из следующих сущностей
Обобщение модели невлияния на вероятностные автоматы
Моделирование компьютерных систем автоматами для изучения вопросов, связанных с безопасностью, началось в середине 1970-х годов (см., например, [66], [68]). Отображение компьютерной системы на автомат оказывалось довольно естественным - входным данным (вводимым командам, приходящим по сети пакетам и т.п.) сопоставлялись буквы входного алфавита, состоянию компьютера (содержимому жесткого диска, оперативной памяти, устройств ввода/вывода и т.п.) сопоставлялись элементы множества состояний. Как правило, рассматривались автоматы без выхода, поэтому нужно было только построить функцию переходов автомата, соответствующую поведению компьютерной системы. Вводилось глобальное понятие безопасности (охватывающее функционирование автомата на произвольных конечных входных словах), затем строились локальные условия, охватывающие переход на некоторое фиксированное число шагов (желательно на один шаг). Таким образом, удавалось строить гарантированно защищенные системы (разумеется, гарантированная защищенность в теории не означает гарантированную защищенность на практике, так как в большинстве моделей, например, аутентификация предполагается абсолютно надежной, а система - работающей без сбоев).
Учитывая сложность современных компьютерных систем (вообще говоря, распределенных и многопользовательских), число состояний становится очень большим. Возникает необходимость огрубления модели за счет меньшей детализации функции перехода.
В данном разделе представлено обобщение автоматной реализации модели невлияния, введенной в [68], на случай вероятностных автоматов. Строятся достаточные и почти необходимые локальные условия (наложенные на матрицу переходов), обеспечивающие глобальную безопасность системы.
Пусть Е — конечное множество, Е — множество всех конечных слов над Е, и є — пустое слово. Под вероятностным автоматом ([9]) понимается тройка А = (5, Е, 6), где 5иЕ суть конечные множества (состояния и входной алфавит, соответственно), a S — функция, определенная на множестве 5хЕи принимающая в качестве значений вероятностные меры на множестве S (обозначим множество таких мер через /л). Для множества В через В обозначим мощность В. Пусть \ S \= п. Тогда /І = (pi... Рп) Pi О, і = 1... n, J2 pi = 1 . Функция 6 может быть определена как некоторое множество стохастических матриц (напомним, что матрица называется стохастической, если все ее элементы неотрицательны и сумма элементов в любой строке равна 1). Пусть Е = га. Тогда S — (Mi... Mm), где Мк — (rfj)" =1- Величина р. имеет смысл вероятности перехода по команде номер к из состояния номер г в состояние номер ,; . Функционирование вероятностного автомата представляет собой некоторый случайный процесс. Пусть Д = (fii .../іп)Є[і — вектор исходного распределения вероятностей (ЦІ есть вероятность того, что до начала работы автомат находился в состоянии Si Є 5), a {Mj... Мт} — система матриц, определяющая функцию S. Тогда поведением вероятностного автомата называется отображение 5 : S х — іл, задаваемое формулой , где а = а(1)... а(к) — входное слово. Функция 6 имеет смысл вероятности попадания в какое-либо состояние при условии заданного начального распределения и поступившего на вход слова. Перечислим допущения о компьютерной системе, моделируемой автоматом А. Пусть в системе работают два пользователя: Н и L. Пользователь Н имеет право знать о системе все, a L — только часть информации. Под безопасностью для А содержательно понимаем ситуацию, когда пользователь L не замечает влияния Н на А. Формализуем это. Пусть == E#UL, то есть у каждого пользователя есть свой набор команд, не пересекающийся с набором другого пользователя. Это предположение не нарушает общности, так как под командой можно понимать пару (идентификатор пользователя, команда). В каждый момент времени только один пользователь может вводить команды. Пусть состояние — вектор параметров, часть которых соответствует пользователю L, а оставшаяся часть — пользователю Н. Исходя из описанной идеологии, формально определим понятие безопасности. Определим безопасное начальное состояние. В силу того, что пользователю L "не положено "видеть результаты работы Н, естественно по- требовать, чтобы в начальный момент в системе не было информации о Я, то есть все /Г-компоненты начального состояния были занулены. Такие начальные состояния мы будем называть безопасными. Начальное распределение состояний называем безопасным, если с вероятностью, равной 1, А находится в первый момент в некотором безопасном начальном состоянии. Введем на S отношение эквивалентности, полагая Sj Sj, если они отличаются только на .//-компонентах. Соответствующие классы эквивалентности индуцируют проектор 7Г : S —У S/ . Пусть [s] — класс эквивалентности s. Введем функцию F : — , определяемую так: если ш = xi... XN, ТО F (Ш) = F(xi)... F(xN), F{xi) = X{ при ХІ Є L и F(xi) = є при Х{ є я Заметим, что F действует на Y, L как тождественное отображение. Занумеруем состояния автомата А так, что сначала берутся состояния, соответствующие первому классу эквивалентности, затем — второму, и так далее. Тогда матрицы вида М могут считаться состоящими из блоков, соответствующих переходу из одного класса эквивалентности в другой. Пусть S/ = I. Обозначим через /J,L множество вероятностных мер на S/ . Рассмотрим проектор т : ц, — //,, задаваемый так. Если pi- соответствует состоянию из г -того класса эквивалентности, ki то полагаем р = ]Г) pip и при Д Є ц выполнено т (Д) = (pf ... pf). i=i Пусть M(l) — множество квадратных матриц размеров 1x1. Определим функцию Адг : YfL — М (I) следующим образом. Пусть и Є Ех, ш = о;(1).. .ш(к) и М — Мш(і) ... Мш(к)- В матрице М происходит объединение состояний, соответствующих одному классу эквивалентности так, что для каждого класса выбирается один представитель, и в качестве вероятности перехода из данного класса в другие берется суммарная вероятность попадания из выбранного состояния в состояния другого класса. Таким образом, от матрицы М размеров п х п переходим к матрице N размеров 1x1 и говорим, что Agr(uj) = N. Вообще говоря, это определение не является корректным, так как оно существенно зависит от выбора представителя класса эквивалентных состояний, однако можно сформулировать условия, при которых функция Адг определена корректно. Содержательно Адг означает переход к процессу с агрегированными состояниями.
Необходимость разделения приложений и сервисов безопасности
Необходимость вынесения сервисов безопасности за рамки приложений и их относительно независимой реализации следует как из общих принципов модульности программного обеспечения, так и из соображений сохранения высокого уровня защищенности информационных систем.
В области информационной безопасности имеют место две противоположные тенденции: снижение уровня защищенности, обеспечиваемого существующими реализациями, как в силу выявления уязвимостей и появления новых методов атак, так и вследствие повышения быстродействия компьютеров и расширения возможностей применения метода "грубой силы"; появление новых реализаций сервисов безопасности, обладающих повышенной защищенностью.
Чтобы поддерживать защищенность И С на высоком уровне, необходимо переходить на новые реализации сервисов безопасности или, по крайней мере, модифицировать старые. Это можно сделать экономически и технически целесообразным образом, только если многочисленные, сложные приложения отделены от сервисов и могут оставаться неизменными.
Ряд сервисов, например, сервис идентификации/аутентификации, целесообразно реализовать централизованно в рамках локальной или корпоративной сети, чтобы, для удобства пользователей, поддержать концепцию единого входа в распределенную систему. Отдельные приложения по мере необходимости удаленно вызывают подобные сервисы, выступая, если это требуется, в роли связующего звена между ними и пользователями или прикладными сущностями. Очевидно, централизованные сервисы должны быть свободны от специфики приложений, а приложения, свою очередь, - от знания специфики сервисов; взаимодействие между ними происходит на основе стандартизованных интерфейсов и/или протоколов.
Уровень защищенности, обеспечиваемый некоторой реализацией сервиса безопасности,со временем имеет тенденцию к снижению. Выявляются дефекты реализации, порой обнаруживаются просчеты алгоритмического плана, за счет повышения быстродействия электронных компонентов становятся применимыми методы грубой силы. Соответственно, для поддержания уровня защищенности требуется постоянное усовершенствование реализаций сервисов безопасности или даже их смена. Сделать это экономически целесообразным образом можно лишь в том случае, когда нет необходимости в перекомпиляции (и, тем более, модификации) прикладного ПО.
Универсальные приложения могут использоваться в разных организациях с различными требованиями к информационной безопасности.
Набор используемых сервисов безопасности и их реализаций также может варьироваться. Более того, иногда требуется применение нескольких реализаций одного сервиса. Например, элемент функциональных требований "Общих критериев"[28] FIA__UAU.5 предписывает использовать сочетание механизмов аутентификации. Выполнить подобные требования при сохранении стабильности приложений можно только в том случае, когда обеспечена возможность динамической или, по крайней мере, конфигурируемой смены набора реализаций сервисов безопасности.
В контексте данной работы встраиваемый модуль является реализацией сервиса безопасности или логически связанного набора функций такого сервиса.
С технической точки зрения встраиваемый модуль - это динамически загружаемый объектный файл. Однотипные модули помещают в определенные каталоги (например, /lib/security), где они могут быть найдены и загружены во время выполнения приложения.
Чтобы избавить приложения от рутинных операций, реализуют библиотеки (менеджеры) встраиваемых модулей, которые берут на себя обработку конфигурационных файлов, поиск и загрузку модулей, осуществляют непосредственное взаимодействие с ними, играя роль прослойки между приложениями и модулями. Библиотеки предоставляют стандартизованный прикладной программный интерфейс сервиса безопасности, обеспечивая приложениям независимость от конкретных реализаций сервиса и от используемого набора таких реализаций, позволяя системному администратору формировать требуемые конфигурации.
Если приложение построено в многоуровневой архитектуре, то соответствующие библиотеки и модули могут располагаться на каждом из уровней. На рис. 3.1 (являющемся обобщением схемы из [67]) показан случай двухуровневой архитектуры клиент/сервер. Сплошными линиями обозначены двунаправленные связи, точечными - однонаправленные.
Взаимодействие между приложениями, библиотеками и модулями происходит локальным (не сетевым) образом. Это, с одной стороны, упрощает написание приложений, поддерживающих использование встраиваемых модулей, а, с другой стороны, не накладывает ограничений на архитектуру всей системы. Во-первых, встраиваемые модули могут взять на себя сетевое взаимодействие с централизованными сервисами безопасности, избавляя приложения от подобных, относительно сложных операций. Во-вторых, они (модули) могут использовать имеющиеся соединения между компонентами приложений, избавляя, в свою очередь, себя от выяснения структуры приложений и от организации удаленного взаимодействия с пользователями и прикладными сущностями.
Встраиваемые модули аутентификации (Pluggable Authentication Modules, РАМ) активно развиваются в ОС Linux под руководством Эндрю Моргана (Andrew Morgan) [67]. Они являются хорошим примером реализации сервиса безопасности на основе описанного выше подхода.
Модули РАМ предоставляют приложениям четыре вида функций: функции аутентификации; функции управления счетами пользователей; функции управления сеансами работы пользователей; функции смены аутентификационных токенов.
Предполагается, что в процессе аутентификации происходит диалог с пользователем:тому посылаются приглашения, в ответ на которые пользователь или клиентская часть приложения предоставляют запрашиваемые данные. Разные методы аутентификации могут потребовать диалогов различной структуры, с разным числом обменов данными. Чтобы обеспечить независимость приложений от специфики модулей РАМ, требуется, чтобы серверная часть предоставляла так называемую диалоговую функцию, реализующую диалог с пользователем и/или клиентской частью. Эту функцию при необходимости вызывают встраиваемые модули, которые таким образом избавляются от зависимости от структуры обслуживаемых приложений и от необходимости поддерживать прямой контакт с (удаленным) пользователем.
Характер диалога модулей РАМ с приложениями - это первый аспект модулей РАМ, заслуживающий детального анализа. Во-первых, взаимодействие с пользователем описывается во встраиваемых модулях процедурными средствами - в виде вызовов диалоговой функции. Известно, что, вообще говоря, декларативные средства описания обладают большей универсальностью и при сопоставимой гибкости являются предпочтительными. Во-вторых, диалог ведется в низкоуровневых терминах отдельных порций данных (текстовых или бинарных). У приложения нет возможности в структурированном виде передать модулям всю известную информацию о пользователе или, в свою очередь, воспринять структурированный запрос набора данных. В-третьих, аутентифицироваться могут не только пользователи, но и иные сущности, для которых поддержка диалога произвольной структуры невозможна. В четвертых, при выполнении диалоговой функции приложение вовлекается в поддержку протокола неизвестной ему (приложению) семантики. С точки зрения информационной безопасности это потенциальная уязвимость, поскольку при наличии вредоносного (в частности, троянского) ПО канал сервер-клиент может быть использован как потайной (subliminal, см., например, [44]).
Требования к операционным системам, реализующим многоуровневую политику безопасности
Со времен "Оранжевой книги"Министерства обороны США [53] требование реализации многоуровневой политики безопасности является обязательным для операционных систем, используемых в режимных организациях и участвующих в обработке информации с грифом секретности. Рассмотрим более современную интерпретацию подобных требований, опираясь на профили защиты и их проекты [5], [64], [6], [69], разработанные на основе "Общих критериев"[60], [61], [62], [74]. С современных позиций ОС можно рассматривать как комбинацию сервисов идентификации и аутентификации, управления доступом и протоколирования/аудита. Кроме того, операционные системы обеспечивают базовые, инфраструктурные свойства безопасности, такие как разделение доменов и посредничество при обращениях. Операционные системы, удовлетворяющие упомянутым выше профилям защиты, должны обеспечивать дискреционное и мандатное управление доступом, мандатное управление целостностью, предоставлять криптографические сервисы. Все пользователи должны иметь ассоциированный уровень допуска, определяющий максимальный уровень чувствительности данных, к которым они могут обращаться. Требования к сервисам идентификации/аутентификации и протоколирования/аудита в целом носят традиционный для ОС характер.
Некоторые отличия (например, включение меток безопасности в записи регистрационного журнала (семейство функциональных требований FAU_GEN), выборочный просмотр аудита на основании меток безопасности (FAU__SAR) или включение в число атрибутов безопасности пользователя данных о допуске (FIA_ATD)) носят вполне очевидный характер. Ни на традиционных (в том числе инфраструктурных) свойствах, ни на рутинных отличиях детально останавливаться не будем. Криптографические сервисы также находятся за пределами рассмотрения в данной работе. Таким образом, основное внимание будет уделено мандатному управлению доступом и ассоциированным вопросам. Вероятно, единственная специфическая угроза для рассматриваемого класса ОС заключается в неадекватной классификации данных на основе их меток, что предоставляет пользователям возможность осуществлять несанкционированный доступ к помеченным данным. В качестве контрмеры провозглашается специфическая цель безопасности: "Операционная система должна предоставлять возможность расставлять точные метки чувствительности и целостности". Существенными в рассматриваемом контексте являются следующие функциональные требования. - Ограниченное управление информационными потоками (FDP_IFC.l). Для назначенных субъектов и объектов и всех опе- раций над этими субъектами и объектами должна осуществляться политика мандатного управления доступом (FDP_IFC.1.1). - Иерархические атрибуты безопасности (FDP_IFF.2). Политика мандатного управления доступом должна основываться на метках безопасности субъектов и объектов (FDP_IFF.2.1). Метка безопас ности должна состоять из иерархического уровня и набора неие рархических категорий. На множестве допустимых меток безопас ности должно быть определено отношение частичного порядка со следующими свойствами (FDP_IFF.2.7): Метки равны, если совпадают их уровни и наборы категорий. Метка А больше метки В, если: уровень А больше уровня
В, и набор категорий В является подмножеством набора А; уровень А равен уровню В, и набор категорий В является собственным подмножеством набора А. Метки несравнимы, если они не равны, и ни одна из меток не больше другой. Для любых двух допустимых меток существует наименьшая верхняя грань, которая больше или равна этим меткам, а также наибольшая нижняя грань, которая не больше обеих меток. Должно поддерживаться по крайней мере 16 уровней и 64 категории. Информационный поток между управляемыми субъектами и объектами посредством управляемой операции разрешен, если метка источника больше или равна метке целевого субъекта или объекта (FDP_IFF.2.2). - Управление атрибутами безопасности (FMT_MSA.l). Функции безопасности должны осуществлять политику мандатного управления доступом с тем, чтобы ограничить право модификации меток безопасности, ассоциированных с объектами. - Роли безопасности (FMT_SMR.l). В число поддерживаемых должна входить роль, дающая право изменять атрибуты безопасности объектов. Для требований доверия безопасности рассматриваемыми профилями предписан оценочный уровень 3, усиленный компонентом ADV_SPM.l (неформальная модель политики безопасности объекта оценки). (напомним, что в ОС Unix понятие файла трактуется обобщенно; в частности, файлами являются устройства (символьные и блочные), а также средства межпроцессного взаимодействия - каналы (pipe)). Для полномасштабной реализации многоуровневой политики, все эти сущности должны получить метки безопасности, учитываемые соответ ствующим образом при определении правомочности выполняемых опе раций. Важнейшую роль играет принятое решение об обеспечении обратной совместимости версий ОС с поддержкой многоуровневой политики безопасности и без таковой. Подобная совместимость необходима для нормальной работы существующих приложений и других программных средств ОС Linux (далее совместимость будет трактоваться именно в таком смысле). Данное решение влечет сохранение структур и форматов файлов, используемых ядром и другими компонентами ОС. Следо вательно, для размещения меток безопасности и иной дополнительной информации должны задействоваться неиспользуемые (резервные) по ля структур или файлов.
При отсутствии или нехватке таковых могут использоваться дополнительные структуры или файлы, однако это нежелательно, поскольку по меньшей мере затрудняет поддержание целостности соответствующей информации. Поскольку основные параметры меток безопасности - число иерархи ческих уровней и мощность набора категорий - должны совпадать для всех сущностей ОС, они (параметры) определяются структурами и фай лами, содержащими минимум резерва. Как будет видно из дальнейшего, в ОС Linux такой сущностью является файл (точнее, описатель файла, хранящийся на диске). Под иерархический уровень удалось выделить 3 бита, под набор (маску) категорий - 61 бит. Это меньше, чем предписывают требования рассмотренных выше профилей защиты. Тем не менее, на нагл взгляд, требование совместимости имеет более высокий приоритет; кроме того, с практической точки зрения, восьми уровней и шестидесяти одной категория вполне достаточно. Наконец, отметим, что логическая структура метки безопасности (см. листинг 4.1) определена "с запасом"и отделена от специфики физического хранения объектов ОС. Это позволяет в будущем с минимальными затратами переносить поддержку мандатного доступа на новые типы файловых систем, в том числе с большим объемом зарезервированного пространства в описателях файлов.
