Современные отечественные разработки в области операционных систем

Содержание.

Введение……………………………………………………………………….3

1. Задачи поставленные перед ОС «Феникс»………………………………..4

2. Архитектура ОС «Феникс»……………………………………………….7

3. Средства защиты ОС «Феникс»……………………………………………12

4.Возможности применения и перспективы развития ОС «Феникс»…….15

Заключение……………………………………………………………………..17

Список литературы…………………………………………………………….18 
Введение

Стремительная информатизация привела к необходимости применения современных компьютерных технологий в областях, где одним из основных требований является безопасность, что привело к появлению таких защищенных систем обработки информации, как ОС «Феникс».

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

1. Задачи поставленные перед ОС «Феникс»

 Сегодня перед отечественными  разработчиками средств защиты  стоят две противоречивые задачи:

• реализовать высокие по мировым меркам требования безопасности, предъявляемые в нашей стране к системам обработки закрытой информации;
• сохранить в полном объеме совместимость с используемыми повсеместно незащищенными прикладными импортными средствами.

Основное противоречие состоит в том, что требование совместимости с популярными импортными средствами подразумевает их использование в составе защищенной системы, что не позволяет в полной мере реализовать предъявляемые требования, поскольку эти средства не рассчитаны на работу в составе систем, критичных к безопасности. Разработчики большинства популярных приложений не ставили перед собой такой задачи в силу изначальной ориентации этих продуктов на массовый рынок средств автоматизации. Действительно, ни один из популярных продуктов не рассчитан на решение задач, связанных с обеспечением безопасности, о чем свидетельствует отсутствие сертификации этих продуктов в западных странах в работоспособной конфигурации. Практически все системы общего назначения, получившие за рубежом сертификаты безопасности, — это специальные защищенные версии Unix типа CX/SX Harris Computer Systems, HP-UX BLS Hewlett Packard, Trusted IRIX/B SGI и т.д. Область применения подобных систем в нашей стране ограничена дорогой эксклюзивной аппаратной платформой, да и сама возможность поставки защищенных версий таких систем вызывает ряд вопросов. Наиболее распространенные у нас продукты Microsoft и Novell никогда не были нацелены на рынок защищенных систем и не получали сертификатов выше C2 по «Оранжевой книге». Следовательно, работа с категорированной информацией в системах такого уровня недопустима. Поэтому отечественный потребитель, нуждающийся в средствах работы с закрытой информацией, в полной мере является заложником ситуации, сложившейся на рынке программных средств, и вынужден искать частные или половинчатые решения.

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

Данный подход к решению задачи построения защищенных систем обработки информации реализуется в Специализированном центре защиты информации Санкт-Петербургского государственного технического университета (СЦЗИ СПбГТУ), а результатом стала операционная система Феникс, которая исходно создавалась как специальная защищенная операционная система класса Unix, отвечающая отечественным требованиями и стандартам информационной безопасности. Разработке этой ОС предшествовали многочисленные исследования в области анализа механизмов нарушения безопасности , выявления источников уязвимостей , разработки моделей безопасности, инвариантных к видам взаимодействий и методов реализации контроля доступа в операционных системах.

2. Архитектура ОС «Феникс»

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

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

Принцип инвариантности определил организацию всех взаимодействий в «Феникс» на основе архитектуры клиент-сервер. Все компоненты выступают в качестве серверов, предоставляющих свои ресурсы другим компонентам, и, в свою очередь, являются клиентами по отношению к другим серверам. Соответственно субъектом взаимодействия всегда является клиент, а объектом — ресурс, поддерживаемый сервером. Таким образом, достигается абстрагирование системы защиты от специфики взаимодействий, но в то же время сохраняется ее гибкость. Контроль и управление доступом могут быть реализованы как на уровне всей системы в целом, так и в составе серверов, обслуживающих ресурсы, что позволяет при необходимости реализовать в серверах специализированные механизмы защиты, адаптированные к специфике обслуживаемых ими ресурсов.

В соответствии с принципом унификации доступ к объектам в «Феникс» осуществляется через УНифицированный Интерфейс Доступа к Объектам (УНИДО), определяющий множество операций, универсальных для всех типов объектов, в виде универсального набора методов, позволяющего выполнять все операции доступа к объектам, их создания и уничтожения, управления их свойствами. Использование УНИДО единственный способ выполнения операций над объектами в «Феникс». Интерфейс оформлен в виде абстрактного класса, от которого наследуются интерфейсы всех серверов «Феникс», реализуемых УНИДО. Наличие набора типовых операций упрощает реализацию контроля доступа, поскольку определено однозначное соответствие между методами УНИДО и операциями доступа, описываемыми моделями безопасности. Кроме того, применение объектно-ориентированной технологии программирования облегчает разработку и расширение возможностей средств защиты.

В соответствии с принципом адекватности архитектура «Феникс» построена таким образом, что контроль и управление доступом осуществляются на основе единой модели представления ресурсов в виде иерархии объектов, доступ к которым осуществляется посредством УНИДО. Такая архитектура не допускает появления привилегированных средств и исключений из общих правил. В состав подсистемы контроля доступа входят всего две процедуры: реализованная в микроядре функция передачи сообщений и специальный монитор взаимодействий, контролирующий доступ к объектам системы. Таким образом, объем программ, корректность функционирования которых критична для безопасности всей системы, сокращен до минимума, поскольку средства контроля являются универсальными для всех видов взаимодействий и типов объектов. Достигнутая с помощью этих решений простота и компактность средств контроля способствует применению формальных методов верификации и анализа программного кода.

Контроль и управление доступом в «Феникс», согласно принципа корректности, реализованы на основе дискреционно-ролевой и принудительной моделей управления доступом. Однако, благодаря инвариантности средств контроля доступа и унификации операций УНИДО, в «Феникс» допускается применение любых моделей безопасности, основанных на контроле взаимодействий субъектов и объектов и управлении атрибутами безопасности. Феникс допускает внедрение новых моделей безопасности без изменения микроядра и средств контроля, причем возможно как независимое применение нескольких моделей для различных подмножеств пространства объектов, так и совместное использование моделей (например, комбинации избирательной и принудительной моделей).

В состав «Феникс» входят следующие компоненты: микроядро, базовые службы, средства защиты, системные службы, прикладные службы, приложения ОС «Феникс», а также набор административных средств, функционирующих в среде Windows и осуществляющих удаленное взаимодействие с «Феникс». Система разрабатывалась как защищенная платформа, поэтому набор приложений минимизирован и состоит из стандартных утилит Unix и специальных средств управления безопасностью.

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

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

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

Особым подклассом базовых служб являются аппаратные драйверы, поскольку только для них микроядро разрешает доступ к аппаратным ресурсам — портам, прерываниям, физической памяти. Драйверы отображают аппаратные ресурсы в объекты «Феникс», которые используются другими службами, не имеющими непосредственного доступа к аппаратуре. Таким образом, только драйверы и микроядро «Феникс» являются аппаратно-зависимыми компонентами, причем реализация микроядра зависит только от механизмов процессора, отвечающих за управления виртуальной памятью и разделения адресных пространств. Остальные службы не содержат аппаратно-зависимого кода.

3. Средства защиты ОС «Феникс»

Основой средств защиты является монитор взаимодействий — специальный компонент, работающий в связке с ядром и осуществляющий контроль взаимодействий в соответствии с политикой безопасности и поставляющий информацию для протокола аудита. Контроль взаимодействий осуществляется следующим образом:

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

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

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