Основы технологии построения

Защищенных ОС.

 

Подходы к обеспечению

Безопасности ОС.

 

Ситуацию противостояния систем защиты и угроз безопасности можно представить себе следующим образом. Существуют ОС со средствами защиты и множество угроз безопасности, которые воздействуют на них (атакуют). Эта ситуация представлена на рис. 6.1. Однако, множество угроз развивается не случайным образом — никто не будет пытаться осуществлять угрозу, которая не имеет ни малейших шансов на успех и не может преодолеть существующие системы защиты. Существование того или иного вида угроз обуславливается наличием в ОС недостатков, описанных в п. 3.4. Таким образом, недостатки в защите ОС как бы провоцируют появление средств нападения. Ситуация напоминает систему с обратной связью — новые атаки приводят к появлению новых средств защиты, а недостатки в средствах защиты приводят к появлению новых средств нападения и т.д.

		недостатки зашиты ОС, делающие возможным осуществление угроз
	Угрозы безопасности и целостности		Операционные системы
		атаки

 

 

 

 

Рис. 6.1. Связь между ОС и угрозами их безопасности

 

Разорвать этот порочный круг бесконечного противостояния можно двумя способами: создать эффективные и безупречно надежные средства защиты от каждого вида нападения, преодолеть которые невозможно, или модернизировать ОС, ликвидировав недостатки защиты, приводящие к успеху средства нападения. Рассмотрим недостатки и преимущества того и другого метода.

Создание средств защиты от каждого вида угроз. Преимущества: защита не зависит от специфики ОС и не требует модификации по мере развития ОС. Недостатки: для создания эффективной системы безопасности необходимо проанализировать все множество угроз и выработать эффективные механизмы противостояния для каждого из видов угроз. Однако практика показывает, что данный путь является тупиковым вследствие следующих факторов:

- множество угроз является открытым и постоянно расширяется и имеет тенденцию экспоненциального роста (см. п. 1.2). Это означает, что все время будут появляться новые угрозы, требующие новых мер защиты, т.к. старые против них бессильны. Появление новых средств защиты, будет приводить к появлению новых классов угроз и т.д. и т.п.

- множество угроз растет не только количественно, но и качественно. Поэтому невозможно создать исчерпывающую классификацию угроз безопасности ВС и предсказывать появление новых типов угроз. Это связано с тем, что для того, чтобы угроза состоялась, она должна быть нового типа и принципиально отличаться от тех, на которые рассчитаны системы защиты.

Устранение причин, приводящих к успешной реализации угроз. Недостатки: зависит от специфики ОС, требует пересмотра некоторых принципов, лежащих в основе работы ОС. Преимущества: не зависит от вида угроз, т. к. ликвидирует причину, а не следствие. Данный метод более эффективен в реализации, чем создание средств защиты от каждого вида угроз. Развитие ОС осуществляется планомерно и контролируемо, а появление новых видов угроз происходит хаотично и непредсказуемо.

Приведенные рассуждения позволяют сделать следующий вывод: для обеспечения адекватности разрабатываемой системы защиты современным угрозам лучше проанализировать те причины, по которым произошли известные случаи нарушения безопасности и ликвидировать их.

 

Задачи разработки

Защищенных ОС.

В предыдущем параграфе было обозначено основное направление развития защищенных ОС — ликвидация причин, приводящих к успешной реализации угроз безопасности. Однако это не означает, что традиционная цель разработки защищенной системы — удовлетворение заданным стандартам защищенности должна быть отодвинута на второй план. Сопоставление причин нарушения безопасности (п. 1.4) и требований к защищенным ОС позволяет утверждать, что устранение причин нарушения безопасности не выходит за рамки стандартных требований к защите ОС. Просто этот подход означает более строгую реализацию требований и их последовательное применение к реальной ОС. Соответствие между причинами нарушения безопасности и требованиями ГТК[2] и МО США [1] показано в таб. 6.1.

Причины нарушения безопасности ОС	Требования ГТК	Требования МО США
Выбор модели безопасности, несоответствующей назначению или архитектуре ВС	Управление доступом Регистрация и учет	Политика безопасности
Неправильное внедрение модели безопасности в систему	Управление доступом	Политика безопасности Непрерывность защиты
Ошибки, допущенные в ходе программной peaлизации систем обеспечения безопасности	Обеспечение целостности	Непрерывность защиты
Отсутствие идентификации и/или аугентификации субъектов и объектов	Управление доступом. Регистрация и учет	Идентификация и аутентификация
Отсутствие контроля целостности средств обеспечения безопасности	Обеспечение целостности	Целостность. Адекватность. Непрерывность
Наличие средств отладки и тестирования в конечных продуктах	Обеспечение целостности	Целостность. Непрерывность

 

Таблица 6.1. Соответствие причин нарушения безопасности ОС

и требований к безопасности.

 

Таким образом, подход к созданию защищенной системы, основанный на ликвидации причин нарушения безопасности, не противоречит реализации требований и стандартов на защищенные системы, а является их расширением.

 

Методы ликвидации причин

Существования угроз.

 

Выбор модели безопасности, соответствующей назначению архитектуре ВС. Правильный выбор модели безопасности фактически является задачей не столько специалистов по ОС, сколько специалистов по безопасности и секретности. Существующие стандарты ограничивают обязательный список моделей только двумя — дискретным и мандатным управлением доступом. Для большинства применений этих двух моделей вполне достаточно. Существующие модели других типов широкого распространения как модели, лежащие в основе ОС, не получили, обычно их используют для разработки того или иного приложения. С другой стороны, исторически сложилось так, что многие системы не поддерживают моделей дискретного и мандатного управления доступом и даже не позволяют внедрить эти модели без существенного нарушения принципов организации системы. Сложности при внедрении этих моделей влекут за собой определенные компромиссы со стороны разработчиков, что является недопустимым, т. к. приводит к искажению модели безопасности и ее некорректной реализации (см. далее). Представляется целесообразным, чтобы ОС общего назначения изначально поддерживали модели дискретного и мандатного управления доступом, начиная с начальных стадий разработки.

Правильное внедрение модели безопасности. Здесь мы не будем останавливаться на этом вопросе, т. к. далее он будет рассмотрен более подробно (см. п. 6.5).

Надежная идентификация и аутентификация объектов и субъектов. Данная проблема носит чисто технический характер. В настоящее время существуют системы, обеспечивающие надежность идентификации и аутентификации с заданной степенью надежности. Для идентификации надежность обеспечивается уникальностью используемых признаков, а для аутентификации — трудностью подделки. Для реализации надежных алгоритмов идентификации и аутентификации пользователей необходимы специальные аппаратные средства — магнитные карты, считыватели физиологических параметров пользователя (отпечатков пальцев, сетчатки глаза и т.д.), программная реализация этих методов несложна и может быть легко добавлена в любую существующую систему. Для идентификации и аутентификации программных (без участия человека) субъектов и объектов используются получившие интенсивное развитие в последнее время алгоритмы т.н. электронной подписи. Выбор конкретных механизмов, устройств и средств идентификации и аутентификации зависит от предъявляемых требований к конкретной системе и можетбыть осуществлен независимо от остальных решений используемых для обеспечения защиты.

Отсутствие ошибок в программной реализации систем обеспечения безопасности. Методы и средства защиты, как и любое другое программное обеспечение подвержены ошибкам реализации. Разумеется, ошибка в любом из компонент системы защиты ставит под сомнение безопасность всей системы, поэтому ошибки в программном обеспечении, отвечающем за безопасность, приводят не просто к потере функциональности, а к дискредитации всей системы. Меры, направленные на решение этой проблемы, относятся к области технологии программирования и надежности ПО. Эта проблема представляет собой как бы область пересечения двух разных дисциплин — безопасности и надежности ПО, т. к. надежность программ, реализующих защиту, определяет безопасность системы.

Контроль целостности средств обеспечения безопасности. Данная проблема носит чисто технологический характер, т.к. методы контроля целостности достаточно развиты и существуют вполне надежные решения (та же цифровая подпись). Однако на практике, как правило, эти методы применяются только для контроля целостности информации (например, при передаче по каналу связи). Для решения этой проблемы необходимо в первую очередь контролировать целостности механизмов, обеспечивающих защиту.

Наличие средств отладки и тестирования в конечных продуктах. Для решения этой проблемы можно использовать только организационные меры. Все системы, для которых безопасность имеет решающее значение должны (кроме всего прочего) иметь сертификат, подтверждающий, что в них отсутствуют подобные возможности. Естественно, что полную ответственность за выполнение этого требования может взять на себя только разработчик.

Ошибки администрирования. Эта проблема упирается в человеческий фактор и не может быть решена чисто техническими средствами. Для минимизации вероятности появления подобных ошибок необходимо обеспечивать средства управления безопасностью и контроля доступа удобным и практичным интерфейсом, по возможности использовать автоматизированные системы управления. Кроме того, можно предусмотреть специальные средства верификации, проверяющие конфигурацию ВС на предмет неадекватного администрирования.

Итак, мы кратко рассмотрели основные методы ликвидации причин успешной реализации угроз безопасности ОС. В данной работе мы подробно остановимся на проблеме внедрения модели безопасности в ОС, и предложим возможные пути ее решения.

 

Проблема внедрения модели

Безопасности в ОС.

 

Критика внедрения моделей.

 

С проблемой внедрения модели безопасности столкнулись все разработчики защищенных ОС. В результате существует некоторый набор частных решений этой проблемы, которые, однако нельзя признать удовлетворительными. Рассмотрим самый простой и очевидный пример — регулирование доступа к файлу, содержащему информацию о пользователях, их идентификаторах и паролях(в ОС Unix /ete/passwd). Применение к этому файлу той или иной схемы разграничения доступа не дает приемлемого решения: если пользователю разрешен доступ только по чтению, то он не может изменить свой пароль, если по чтению и записи, то он может поменять пароль не только себе, но и другим, если у него вообще нет доступа к этому файлу, то он не сможет узнать имена других

пользователей и будет вынужден работать с идентификаторами других пользователей. Все эти варианты абсолютно неприемлемы. Выход находился в том, что пользователям давалось право только на чтение, а администратору — на чтение и запись. Это решает все проблемы, кроме одной — как пользователю изменить свой пароль (ведь для этого необходимо осуществить запись в этот файл). Для выхода из создавшегося положения используется неформальный подход — вводится специальная программа, которая при запуске обладает правами администратора и изменяет для пользователя его пароль. Недостатки такого подхода очевидны.

Во-первых, в используемой в системе безопасности появились исключения, что не предусматривается ни одной моделью разграничения доступа.

Во-вторых, появилась новая проблема — т. к. программа, обладающая правами администратора, может быть запущена любым пользователем, необходимо доказать, что она не нанесет ущерба безопасности и целостности системы, а ее действия ограничатся только изменением информации, относящейся к пользователю, который ее запустил.

В-третьих, эта программа представляет собой очень уязвимую точку в системе защиты — значит необходимо обеспечить, а также постоянно контролировать ее целостность.

Отметим, что при использовании этой схемы для пользователя доступ по записи к файлу паролей возможен только с помощью этой специальной программы, что нарушает принятый во многих ОС стиль работы и в некоторых ситуациях доставляет неудобства. Рассмотренный пример, конечно, не представляет из себя неразрешимой проблемы, однако он очень характерен — в современных ОС присутствует огромное количество различных служб (сетевые службы, графический интерфейс, файловые системы и т.д.), каждая из которых включает в себя файл, содержащий информацию о конфигурации службы, режимах работы, пользователях и т.д. Очевидно, что это очень критичная информация, однако при разграничении доступа к ней возникают примерно те же проблемы.

Таким образом, существующее положение с внедрением модели безопасности в ОС нельзя назвать удовлетворительным, т к остаются нерешенными следующие проблемы:

1. Допускается исключение из правил, регулирующих доступ согласно модели безопасности. Это означает, что теоретические достижения, связанные с доказательством эффективности модели на практике оказываются утерянными, т. к. доказательство не учитывает этих исключений.

2. Данный подход искусственно порождает новую проблему — проверку корректности работы программ, представляющих собой исключение из модели безопасности. Это приводит к необходимости формального доказательства корректности работы этих программ, что представляет собой немалую проблему и не служит непосредственной цели — обеспечению безопасности системы.

3. Безопасность всей системы зависит не только от реализации в ее ядре модели безопасности, но и от корректности программ, являющихся внешними по отношению к самой ОС. Это противоречит основным требованиям к безопасности для систем высокого класса защищенности.

Итак, мы показали, что проблема внедрения модели безопасности весьма актуальна и без ее эффективного решения создания защищенной системы невозможно. Для решения этой проблемы необходимо формально постановить задачу внедрения модели безопасности в ОС, после чего можно предложить ее решение.

 

6.4.2. Постановка задачи внедрения модели безопасности в ОС.

 

Рассмотрим подробнее проблему внедрения модели безопасности в ту или иную ОС. Как было отмечено в главе 2, существующие модели безопасности достаточно хорошо проработаны, формально доказаны и их надежность (с точки зрения теории) не вызывает сомнений Особенно это относится к двум основным моделям, используемым в качестве обязательных ГТК РФ[2] и МО США[1] — моделям дискретного и мандатного управления доступом. Однако при детальном изучении этих моделей становится очевидно, что все они достаточно далеки от практики, т к оперируют абстрактными понятиями типа объект, субъект и т.д. В них отсутствуют такие понятия, как пользователь, процесс, файл, каталог, удаленный пользователь, сетевое соединение и т.д, которые используются для описания функционирования современных ОС. С одной стороны это дает преимущество в виде свободы трактовать понятия объект и субъект по отношению к различным ситуациям, а с другой — приводит к появлению проблемы внедрения модели безопасности в реальную ОС. Эту проблему можно сформулировать следующим образом:

Имеется модель безопасности, состоящая из набора объектов, субъектов, и правил, определяющих права и вид доступа субъектов к объектам. Кроме того, имеется ОС, которая содержит такие сущности, как данные, процессы, приложения и т.д. Для успешного внедрения модели безопасности в ОС необходимо установить однозначное соответствие между объектами и субъектами модели безопасности и реальными сущностями, которые присутствуют в ОС.

Установить это соответствие совсем непросто — может не быть однозначного отображения объектов в сущности ОС Например, документ может содержаться не в одном, а нескольких файлах Более того, в ОС имеются сущности, которые не соответствуют ни одному объекту модели (например, конфигурационные файлы) и поэтому из модели не следует каким образом регламентировать доступ к ним. Для того, чтобы решить эту проблему, необходимо найти такой способ отображения модели на ОС, при котором не нарушаются адекватность модели.