Содержание к диссертации
Введение
Глава 1. Современное состояние проблемы, постановка задачи 9
1.1. Обзор современных операционных систем 14
1.2. Общая архитектура защищенной микроядерной системы 31
Выводы к главе 1 39
Глава 2. Реализация моделей безопасности 40
2.1. Подсистема разграничения доступа 40
2.2. Адекватность внедрения моделей 49
Выводы к главе 2 53
Глава 3. Архитектура защищенной микроядерной ОС 55
3.1. Основные модули микроядерной ОС 55
3.1.1. Микроядро 55
3.1.2. Функциональные серверы 61
3.1.3. Средства защиты 64
3.2. Модели программных компонент ОС 72
3.2.1. Модель микроядра 72
3.2.2. Модели средств защиты 74
3.2.3. Модель функционального сервера 77
3.3. Реализация подсистемы РПД 79
3.4. Корректность программных компонент 89
3.4.1. Корректность микроядра 89
3.4.2. Корректность функциональных серверов 92
3.5. Программные интерфейсы компонент ОС 101
3.5.1. Интерфейс микроядра 101
3.5.2. Унифицированный интерфейс доступа к объектам 102
3.5.3. Интерфейсы серверов 105
Выводы к главе 3 108
Глава 4. Обеспечение мобильности защищенных систем 110
4.1. Методика обеспечения мобильности 110
4.2. Реализация программных интерфейсов мобильных систем 117
Выводы к главе 4 125
Глава 5. Практическая реализация макета защищенной ОС 127
5.1. Архитектура защищенной ОС 127
5.2. Подсистема разграничения доступа 132
Выводы к главе 5 140
Заключение 142
Список литературы 144
- Общая архитектура защищенной микроядерной системы
- Адекватность внедрения моделей
- Модели программных компонент ОС
- Реализация программных интерфейсов мобильных систем
Введение к работе
В настоящее время благополучие и даже жизнь многих людей зависят от обеспечения информационной безопасности множества компьютерных систем обработки информации, контроля и управления различными объектами. К таким критическим системам можно отнести системы телекоммуникаций, банковские системы, системы военного назначения, системы управления транспортом, системы обработки и хранения секретной и конфиденциальной информации. Функционирование критических систем невозможно без обеспечения их безопасности и целостности.
Основой для построения безопасных вычислительных систем (ВС) являются защищенные операционные системы (ОС). Несмотря на значительные теоретические наработки в области информационной безопасности, разрабатываемые специализированные защищенные ОС либо остаются на стадии проектов, либо не получают широкого распространения по причине недостаточной гибкости и сложности эксплуатации. Подавляющее большинство современных ОС являются зарубежными разработками, их использование для ряда критических систем является неприемлемым, а на практике ограничивается действующими требованиями информационной безопасности, что еще больше затрудняет разработку безопасных ВС. Из изложенного следует постановка задачи разработки методов построения ОС, обеспечивающих необходимые функции защиты ВС.
Важнейшим фактором, определяющим показатели безопасности системы, является архитектура защиты, как способ интеграции в систему средств защиты. Неадекватное внедрение средств защиты, главным из которых является подсистема разграничения прав доступа (РПД), является основной причиной нарушений безопасности. Эта проблема в настоящее время исследуется в трудах таких ученых, как В.А. Герасименко, Л.М. Ухлинов, СП. Расторгуев, К.Лендвер, Д.МакЛин, Д.Кларк, Д.Миллен. В настоящее время не существует общепринятого подхода к построению и обоснованию архитектуры защиты ОС. На проектные решения оказывают влияние не только требования безопасности, но и взаимозависимость механизмов обработки информации и средств защиты, предъявляемые к системе функциональные требования и требования совместимости. В диссертационной работе предложен и применен на практике комплексный подход к построению архитектуры защиты ОС, позволяющий реализовать на ее основе широкий класс политик безопасности, обосновать адекватность внедрения средств защиты и определенный уровень надежности системы.
Целью работы является обеспечение гибкости управления доступом в ВС на основе универсальной модели взаимодействия ее компонентов.
Для достижения поставленной цели в работе решались следующие задачи:
1. Разработка общей архитектуры защищенной ВС, поддерживающей унифицированные механизмы взаимодействия компонентов и разделение средств обработки информации и средств защиты.
2. Анализ основных моделей безопасности и определение необходимых для реализации широкого класса моделей безопасности требований к функциональным компонентам системы.
3. Разработка функциональных моделей основных доверенных компонентов системы, в том числе средств защиты, входящих в состав подсистемы РПД.
Разработка методики обеспечения мобильности защищенной ОС.
Практическая реализация макета защищенной ВС.
Для решения поставленных задач использовались теория программирования и системный анализ, методы объектно-ориентированного анализа и проектирования, теория алгоритмов, теория множеств и математическая логика.
Научная новизна диссертационной работы состоит в следующем:
1. Разработан подход к реализации защищенных ВС, обеспечивающих поддержку широкого класса моделей безопасности.
Впервые формализована задача реализации средств управления доступом в ОС, поддерживающей унифицированные механизмы взаимодействия и доступа к ресурсам.
Формально обоснована адекватность внедрения подсистемы РПД для систем микроядерной архитектуры.
Предложена методика обеспечения мобильности защищенных систем, их совместимости с существующими системами на уровне программных и пользовательских интерфейсов.
Практическая ценность работы определяется возможностью использования предложенной в ней общей архитектуры системы и моделей компонент для разработки защищенных ОС. Предложенные в работе подходы к разработке защищенных ОС были использованы при разработке в специализированном центре защиты информации Санкт-Петербургского Государственного технического университета (СЦЗИ СПбГТУ) мобильной защищенной операционной системы, которая содержит подсистему РПД, поддерживающую дискреционную и мандатную модели безопасности, и является совместимой с ОС UNIX. Данная ОС используется для построения защищенных ВС специального назначения. Акт об использовании системы прилагается к работе.
Основные теоретические и практические результаты работы обсуждались на Российской научно-технической конференции "Методы и технические средства обеспечения безопасности информации" в 1998-
2000г., международной научно-технической конференции "Техника и технология связи" в 2000г.
Основные положения, выносимые на защиту:
1. Общая архитектура защищенной ВС на основе микроядра.
2. Модели микроядра, функционального сервера и основных средств защиты.
3. Обоснование возможности реализации в предлагаемой архитектуре подсистемы РПД, поддерживающей широкий класс моделей безопасности.
Методика обеспечения мобильности защищенной ОС.
Макет защищенной мобильной ОС с внедренной подсистемой РПД, поддерживающей мандатную и дискреционную модели безопасности.
Диссертация состоит из введения, пяти глав, заключения и списка литературы из 68 наименований.
В первой главе рассматриваются современные подходы к разработке защищенных систем, анализируются основные недостатки архитектур защиты существующих ОС, обосновывается и формулируется задача разработки защищенных мобильных ОС на основе микроядерной архитектуры.
Во второй главе анализируются основные классы математических моделей безопасности и их применимость для предлагаемой архитектуры. Определяются требования к функциональным компонентам системы, необходимые для адекватной реализации моделей безопасности.
В третьей главе рассматривается предлагаемое автором решение задачи адекватного внедрения в микроядерную ОС подсистемы РПД. Определяются модели основных доверенных программных компонент защищенной ОС. Доказывается возможность адекватного внедрения моделей безопасности при построении системы на базе этих моделей.
Выполняется проектирование программных интерфейсов доверенных компонент.
В четвертой главе рассматривается проблема обеспечения мобильности защищенной ОС. Определяется достижимый уровень совместимости с существующими мобильными системами. Предлагается общая методика обеспечения совместимости программных интерфейсов защищенной ОС с интерфейсами незащищенных мобильных систем. Описывается решение задачи обеспечения совместимости микроядерной защищенной ОС предлагаемой архитектуры и ОС UNIX.
В пятой главе описывается пример практического применения предлагаемых архитектурных и программных решений при построении защищенных ВС. Описываются результаты проекта создания локальной вычислительной сети (ЛВС), управляемой защищенной мобильной ОС. Данная ОС является оригинальной разработкой Специализированного Центра Защиты Информации (СЦЗИ) СПбГТУ.
Общая архитектура защищенной микроядерной системы
На основании проведенного анализа современных защищенных ОС можно утверждать, что их существенными недостатками являются наследование архитектурных решений, характерных для незащищенных систем, и невозможность гибкого изменения политики безопасности.
При разработке первых версий защищенных систем важнейшими требованиями являлись обеспечение формального соответствия установленным требованиям информационной безопасности и максимально полной совместимости с предшествующими версиями систем. Если проблема совместимости была решена достаточно успешно, то архитектура защиты, как способ интеграции в систему средств защиты и организации их взаимодействия с другими компонентами системы, может быть подвергнут серьезной критике. Внедрение подсистемы РД с расширенными, по сравнению с традиционными системами, возможностями проводилось в зависимости от особенностей системы. Не было осуществлено четкого разделения модулей ОС на средства обработки и средства защиты информации, соответственно не была решена проблема исключения взаимного влияния различных доверенных компонент, входящих в ТСВ системы, защиты средств защиты. Характеристики средств защиты определяются жестко, и если возможности ОС в этом отношении не вполне соответствуют требованиям к разрабатываемым на их основе ВС, то проблема внесения изменений или дополнений в архитектуру защиты практически не имеет решений без коренной переработки ОС.
Основными факторами, определяющими выбор архитектуры системы, являются аппаратная платформа, требования безопасности, функциональные требования к системе и требования совместимости (рис. 1.1). Наибольшую трудность при проектировании представляет минимизация взаимовлияния этих часто противоречивых факторов.
Аппаратная платформа определяет способы реализации базовых механизмов изоляции компонент системы и их взаимодействия. Используемый в системе набор аппаратных устройств оказывает влияние на возможности функциональных модулей. Достаточно успешно в современных системах решается только задача обеспечения независимости от аппаратной платформы программных и пользовательских интерфейсов.
Требования совместимости с существующими (часто незащищенными) системами и их программными и пользовательскими интерфейсами оказывают влияние как на возможности реализуемых в системе средств хранения и обработки данных, так и на характеристики средств защиты. В случае использования в двух системах различных сущностей или протоколов доступа к ним, для обеспечения совместимости должны быть предусмотрены механизмы преобразования обращений или модули, непосредственно поддерживающие сущности, характерные для другой системы. Для строгой совместимости с политиками безопасности, используемыми в других системах, может потребоваться реализация специальных средств защиты или расширение свойств существующих (например, как в Windows NT). С другой стороны, на уровне интерфейсов системы находят отражение механизмы управления реальными функциональными модулями и средствами защиты данной системы.
Для обеспечения безопасности системы особую важность представляет взаимозависимость функциональных требований и требований безопасности. Она выражается в том, что при проектировании функциональных модулей, поддерживающих определенные ресурсы и объекты системы и выполняющих операции над ними, необходимо учитывать как непосредственно функциональные требования, так и требования безопасности. На возможность реализации определенной модели безопасности или политики управления системными ресурсами оказывают влияние абстракции, поддерживаемые функциональными модулями ОС, алгоритмы их работы и механизмы обращений к этим модулям. Очевидно, что можно предложить такие методы реализации функциональных требований, что реализация требований безопасности будет невозможна.
На практике функциональные требования часто рассматриваются как первичные, на первом этапе ведется проектирование всех подсистем, обеспечивающих работоспособность системы и выполнение ею своих непосредственных функций, а затем происходит разработка и внедрение средств защиты, в частности - подсистемы РД, с возможной корректировкой функциональных возможностей ОС. Например, при разработке файловой системы сначала производится проектирование системы исходя из функциональных требований к ней с резервированием ресурсов для хранения атрибутов безопасности файлов и заглушками функций контроля доступа к файлам, а затем производится уточнение набора атрибутов безопасности и реализация функций контроля доступа соответствующих определенной модели безопасности. Очевидно, что при таком подходе к построению архитектуры системы внедрение гибких механизмов управления доступом невозможно, поскольку изменение модели безопасности требует внесения изменений в различные функциональные модули ОС.
Гибкость средств управления доступом может быть достигнута только при максимальном разграничении функций обработки информации и функций защиты. В пределе они должны реализовываться независимыми модулями. Такой подход может быть реализован на основе унификации механизмов взаимодействия компонент системы и механизмов доступа к объектам и ресурсам системы. Тогда контроль доступа к объектам и ресурсам может быть реализован единообразно для всех функциональных модулей, а изменения модели управления доступом может быть произведено путем изменения только средств защиты и не будет затрагивать функциональные модули системы.
Для реализации такого подхода наиболее удобной является микроядерная архитектура. Она характеризуется унификацией механизмов взаимодействия процессов, унификацией способов идентификации объектов и ресурсов системы, унификацией механизмов доступа к ресурсам и объектам системы, высокой модульностью.
Микроядерная архитектура используется в большинстве вновь разрабатываемых современных ОС. В ее основе лежат минимизация функций ядра и использование технологии клиент-сервер при взаимодействии компонентов системы [60]. Микроядро обеспечивает изоляцию процессов и поддерживает минимизированный набор элементарных механизмов взаимодействия активные субъектов системы (процессов, задач). Все приложения системы разделяются на доверенные (ТСВ системы) и недоверенные. Доверенные приложения (сервера ОС) управляют объектами и ресурсами системы и реализуют функции защиты, в частности разграничивают доступ к объектам ОС недоверенных приложений, действующих от имени пользователей системы. Обращения к объектам и ресурсам, поддерживаемым серверами, осуществляются путем явных обращений к этим функциональным серверам через механизмы взаимодействия процессов. Унификация способов идентификации объектов и ресурсов и интерфейсов доступа к ним достигается при реализации всех функциональных серверов на основе единой концепции функционального сервера. Высокая модульность архитектуры системы определяется наличием большого числа параллельно работающих серверов, для каждого из которых четко определенны его функции в системе.
Адекватность внедрения моделей
Применимость модели безопасности при контроле обращений к объектам функционального сервера определяется реализуемым данным сервером алгоритмом обработки запросов. В общем случае нельзя гарантировать адекватность применения модели безопасности для разграничения доступа к объектам сервера, если она не предусматривалась при проектировании сервера.
Рассмотрим следующий пример функционального сервера. Пусть сервер поддерживает два объекта - oi и 02 и реализует для них операции чтения и записи. При этом при чтении из объекта 02 клиентам возвращается число операций записи, выполненных сервером над объектом oi. Реализация произвольной мандатной или дискреционной модели безопасности для сервера с таким алгоритмом обработки запросов является затруднительной. Причиной этому является взаимозависимость объектов сервера. Разграничение доступа к объектам сервера при помощи дискреционной политики не имеет смысла, поскольку изменение состояния одного объекта возможно при помощи обращения к другому. Мандатная модель может использоваться, только если Ог назначается более высокий уровень безопасности Оь
Следует отметить, что данный пример не является спекулятивным. Аналогичная схема используется при организации файловых систем, когда клиенты имеют возможность не только чтения и записи данных в файлы, но и получения информации о текущем состоянии файловой системы, например, объеме свободного дискового пространства. Очевидно, что такая схема позволяет организовать скрытый канал утечки информации, нарушающий политику безопасности.
Приведенный пример демонстрирует важность согласования операций функциональных серверов и типов доступа моделей безопасности. При этом согласование должно быть двусторонним, с одной стороны операции серверов должны быть представимы в терминах типов доступа, с другой - должны существовать операции, представляющие каждый из типов доступа. При нарушении первого условия будет невозможно адекватное представление реальных взаимодействий в системе в терминах модели безопасности. При нарушении второго - может оказаться невозможным организовать информационные потоки в ВС в соответствии с логикой реализуемой модели безопасности.
С учетом сказанного формулируются требования к функциональному серверу, необходимые для адекватной реализации некоторой модели безопасности при обращении к объектам сервера: должны быть определены множества возможных состояний объектов, поддерживаемых сервером, и всех ресурсов сервера; - должно быть определено множество поддерживаемых сервером операций; - каждая реализуемая сервером операция над объектами и ресурсами должна быть представима алгоритмом, описывающим последовательность методов доступа в терминах модели безопасности; - каждый метод доступа, определяемый моделью безопасности, должен быть реализуем при помощи как минимум одной операции функционального сервера; - указанные условия должны соблюдаться для всех типов объектов, которые поддерживает сервер.
Рассмотрим основные функциональные сервера микроядерной системы, типы поддерживаемых ими объектов и выполняемые над объектами операции. Сервера файловых систем должны поддерживать объекты типа регулярный файл, каталог, программный канал (fifo-файл). Сервера стеков сетевых протоколов должны поддерживать объекты типа сетевой сокет. Виртуальные терминалы, поддерживаемые сервером терминалов, представляются в виде пары направленных программных каналов - входного и выходного потока данных. Таким образом, реализация заявленных функциональных требований к ОС возможна при использовании серверов, поддерживающих объекты двух метатипов -хранилище данных и канал передачи данных.
Анализ алгоритмов работы соответствующих программных модулей современных ОС показывает, что любая операция, выполняемая функциональными серверами по запросам клиентов над объектами указанных типов, может быть сведена к последовательности элементарных операций над отдельными объектами. При этом каждая элементарная операция будет относиться к одному из типов метаопераций - чтения и записи содержимого объектов, создания и удаления объектов, получения и установки их атрибутов. Операции получения и установки атрибутов безопасности субъектов и объектов, в соответствии с заявленным принципом разделения функций обработки и защиты информации, реализуются непосредственно средствами защиты и не входят в набор операций функциональных серверов.
Указанные типы метаопераций близки к типам доступа, определяемым моделями безопасности. Операции получения атрибутов представляются как доступ по чтению. Операции записи установки атрибутов - как доступ по записи. Удаление объекта может быть представлено, как доступ по удалению объекта, по стиранию или по записи, в зависимости определяемых моделью от типов доступа. Создание объекта представляется либо как доступ по созданию, либо, если используемая модель не определяет такой тип доступа, контролируется политикой управления системными ресурсами.
Модели программных компонент ОС
Процесс ОС можно рассматривать как совокупность виртуального адресного пространства AS и атрибутов AT. Адресное пространство определим как множество доступных процессу страниц памяти. Атрибуты процессов хранятся в адресном пространстве микроядра. Они включают идентификатор, тип и пользовательский идентификатор. P={AS,AT}, (3.2.1) где Назовем информационным объектом ОС логическую совокупность бит, расположенную на любом носителе данных, находящимся под управлением ОС. Будем говорить, что информационный объект d находится в адресном пространстве процесса Pi deASi, если адресное пространство процесса содержит все страницы памяти, хранящие биты информационного объекта. Примерами информационных объектов являются содержимое файла, массив данных или сообщение.
Определим модель микроядра как совокупность функций, выполняемых микроядром над процессами ОС (таб. З.1.). Функции выполняется микроядром по запросам процессов ОС. Ядро может параллельно обрабатывать несколько запросов от различных процессов или одного многопоточного процесса.
Определим аргументы функций, выходные параметры и изменения в состоянии выходных параметров на момент завершения обработки функций в случае успешного их выполнения.
Неявным выходным параметром для каждой функции будет состояние структур данных микроядра. После обработки функции микроядро передает в адресное пространство вызвавшего ее процесса (Ра) информационный объект, содержащий код завершения. Этот объект генерируется микроядром и не включает информации, содержащейся в других информационных объектах ОС. Если ядро не смогло выполнить функцию, то никаких изменений в состоянии процессов, за исключением передачи кода завершения, не производится.
Каждая функция затрагивает состояние не более двух процессов ОС - активного процесса Ра, обратившего к функции ядра, и пассивного Рр, взаимодействие с которым осуществляет Ра.
Модель включает только операции, допустимые после завершения инициализации ОС, старта всех функциональных серверов, средств защиты и процессов псевдо-пользователей. В нормальном режиме работы системы из атрибутов процессов изменяться может только пользовательский идентификатор процесса.
Функция AttrSet выполняется микроядром только для сервера аутентификации, функция MessageCheck - только для монитора ссылок.
Рассмотрим специальные функции по управлению процессами, выполняемые монитором ссылок и сервером аутентификации.
Монитор ссылок выполняет анализ сообщений, отправляемых другими процессами ОС. При проверке, прежде всего, учитывается допустимость потока данных между процессом-отправителем и процессом-получателем. При проверке сообщения, направленного функциональному серверу, монитор ссылок дополнительно производит интерпретацию запроса, определяет объекты ОС и операции, которые будут выполнены над ними в результате обработки запроса сервером, и принимает решение о допустимости выполнения этих операций по запросу субъекта ОС, от имени которого действует процесс-отправитель.
Проверка сообщения монитором ссылок является частью процедуры обработки сообщений в микроядре. Инициатором во взаимодействии между микроядром фактически выступает микроядро. При помощи функции ядра MessageCheck монитор ссылок копирует проверяемое сообщение в собственное адресное пространство, проводит его анализ и передает микроядру решение о допустимости передачи сообщения получателю.
Основной операцией, выполняемой монитором ссылок, является проверка отдельного сообщения.
Кроме проверки сообщений монитор ссылок выполняет все операции по управлению атрибутами безопасности субъектов и объектов. Набор атрибутов безопасности и возможные операции над ними определяются моделями безопасности, которые поддерживает монитор ссылок. Запрос на выполнение операций над атрибутами безопасности объекта оформляется как сообщение функциональному серверу, поддерживающему этот объект. Монитор ссылок после анализа сообщения самостоятельно обрабатывает запрос и возвращает результат обработки посредством функции MessageReply. Аналогично монитор ссылок обрабатывает операции над атрибутами безопасности субъектов, определяемые моделями безопасности. Остальные запросы, например, на создание субъекта или его изменение пароля, после проверки монитором ссылок обрабатываются сервером субъектов.
Реализация программных интерфейсов мобильных систем
Реализация программных интерфейсов традиционных ОС в системе с микроядерной архитектурой является достаточно распространенной задачей. Примерами ее решения являются подсистема POSIX в ОС Windows NT, система Trusted Mach, а также разработки микроядерных версий ОС UNIX - систем OSF/1 и Workspace на базе микроядра Mach, Chorus/Mix V.3 на базе микроядра Chorus, ОС Plan 9. При разработке защищенных систем существенным требованием является минимизация влияния механизмов поддержки внешних программных интерфейсов на общую архитектуру системы и сохранение свойств безопасности при обработке информации с использованием данных механизмов. К сожалению, данное требование не всегда выполняется как при создании систем, где программная среда POSIX является лишь одной из нескольких поддерживаемых в системе, так и при разработке версий UNIX, где POSIX является основным интерфейсом. Недостатки реализации подсистемы POSIX для Windows NT и Trusted Mach были подробно рассмотрены в первой главе работы.
Для предлагаемой архитектуры ОС решением, при котором внедрение программных интерфейсов мобильных систем оказывает минимально возможное влияние на архитектуру, является сохранение состава доверенных программных компонент и разработанных интерфейсов доступа к ним и реализация высокоуровневых программных интерфейсов в рамках каждого из процессов приложений ОС, использующих эти интерфейсы. Тогда все процессы ОС - и доверенные процессы функциональных серверов и средств защиты, и недоверенные процессы пользователей - будут использовать при взаимодействиях только системные программные интерфейсы, полностью соответствующие используемой архитектуре и сохраняющие доказанные свойства безопасности. Решение задачи поддержки совместимости достигается не разработкой дополнительных программных компонент, а созданием специализированной среды их разработки.
Проведем анализ программных интерфейсов POSIX и системных программных интерфейсов доверенных компонент защищенной микроядерной ОС в соответствии с предложенной методикой обеспечения мобильности. 1. Программные интерфейсы UNIX по функциональному назначению разделяются на несколько основных групп. Системно-независимые функции, выполняющие арифметические и символьные вычисления, обработку строк и массивов переносятся без изменений. Функции, управляющие жизненным циклом процесса, обработкой времени, функции доступа к файловым системам, базового ввода-вывода и стандартного буферизованного ввода-вывода, функции работы с сокетами и механизм сигналов реализуются с использованием обращений к микроядру и функциональным серверам. Обращения к файлам, каталогам, устройствам, сокетам и другим объектам ядра UNIX, преобразуются в запросы к объектам, поддерживаемыми функциональными серверами защищенной ОС, в соответствии с УНИДО. Функции, обеспечивающие в UNIX многопользовательскую защиту, в общем случае не могут быть адекватно реализованы и должны быть заменены на заглушки. 2. Функции, выполняющие управление средствами защиты, определяются поддерживаемыми моделями безопасности и политикой управления ресурсами, они должны проектироваться с учетом особенностей конкретной ВС и ее политики безопасности. На основании общего состава средств защиты и их ролей в системе можно утверждать, что необходимо разработать функции управления атрибутами безопасности субъектов и объектов, управления пользователями системы и системными ресурсами, настройки подсистемы аудита, и управления средствами аутентификации, отражающие возможности средств защиты и микроядра защищенной ОС.
Интерфейсы этих функций должны соответствовать общим требованиям к функциям ОС UNIX. 3. В целом микроядро и функциональные сервера обеспечивают возможность использования на уровне пользовательских процессов основных механизмов взаимодействия процессов и абстракций интерфейса POSIX: файлов, каталогов, специальных файлов устройств, сетевых сокетов, механизмов синхронизации процессов и т.д. Тем не менее, существуют механизмы POSIX, реализация которых вызывает определенные трудности. Например, эффективная реализация разделяемой памяти или отображения содержимого файлов в адресное пространство процессов на базе предлагаемого микроядра невозможна, синхронная система сообщений затрудняет реализацию асинхронных сигналов, поддержка стандартных терминалов UNIX или графического интерфейса пользователя целиком определяется функциональными возможностями сервера виртуальных терминалов. Несмотря на указанные ограничения внедрение интерфейса POSIX возможно без изменения состава функциональных серверов. Важнейшим требованием ко всем функциональными серверам является обеспечение доступа к объектам ОС по именам и поддержка общесистемной иерархии имен объектов. Каждый объект ОС имеет уникальный общесистемный идентификатор. Единственным способом доступа к объекту является отправление запросов функциональному серверу, поддерживающему этот объект.
