eng
Выпуск #10/2023
С. Назаров, А. Барсуков
НАДЕЖНОСТЬ И БЕЗОПАСНОСТЬ ОПЕРАЦИОННЫХ СИСТЕМ РАЗЛИЧНОЙ АРХИТЕКТУРЫ. ЧАСТЬ 3
НАДЕЖНОСТЬ И БЕЗОПАСНОСТЬ ОПЕРАЦИОННЫХ СИСТЕМ РАЗЛИЧНОЙ АРХИТЕКТУРЫ. ЧАСТЬ 3
Просмотры: 471
DOI: 10.22184/1992-4178.2023.231.10.80.86
Рассматривается модель операционной системы Касперского. Отмечается, что кибериммунный принцип ее построения повышает надежность и безопасность операционных систем KasperskyOS по сравнению с системами другой архитектуры.
Рассматривается модель операционной системы Касперского. Отмечается, что кибериммунный принцип ее построения повышает надежность и безопасность операционных систем KasperskyOS по сравнению с системами другой архитектуры.
Теги: kasperskyos microkernel simulation theory of markov processes имитационное моделирование микроядро kasperskyos теория марковских процессов
Надежность и безопасность операционных систем различной архитектуры. Часть 3
С. Назаров, д. т. н., А. Барсуков, к. т. н.
В заключительной части статьи представлена модель операционной системы Касперского. На сегодняшний день KasperskyOS – это микроядерная частично POSIX-совместимая операционная система, не являющаяся системой общего назначения. Ее основное предназначение – разработка ИТ-продуктов для отраслей с повышенными требованиями к кибербезопасности, надежности и предсказуемости работы. Однако реальна возможность ее развития до операционной системы универсального применения. Цель статьи – показать, насколько кибериммунный принцип построения системы повышает надежность и безопасность создания операционных систем по сравнению с системами другой архитектуры.
Особенности архитектуры KasperskyOS
Прежде всего, надо отметить, что система полностью создана с чистого листа специалистами «Лаборатории Касперского», является оригинальной разработкой компании и зарегистрирована в реестре российского ПО как рекомендованная для приобретения отечественными организациями и государственными структурами [18]. Основой ОС служит надежное микроядро, которое допускает только строго определенный способ взаимодействия системных процессов и обмена данными, тем самым обеспечивая полноту контроля доступа. Будучи компактным, оно может портироваться на различные аппаратные платформы. KasperskyOS построена на базе концепции MILS (Multiple Independent Levels of Security – «множественные независимые уровни защиты/безопасности»), определяющей строгие принципы изоляции системных процессов и политик управления информационными потоками. Одним из наиболее важных компонентов ОС является модуль контроля доступа Kaspersky Security System (KSS), отслеживающий все межпроцессорные взаимодействия и исключающий доступ приложений к защищенным областям памяти с критически важными процессами и данными. KSS поддерживает широкий набор правил и политик доступа и может быть настроен в соответствии с конкретными требованиями заказчика. Любое действие, не предусмотренное политиками безопасности, запрещено по умолчанию. И это, пожалуй, самое важное отличие KasperskyOS от популярных сегодня операционных систем, в которых все, что не запрещено, по умолчанию разрешено.
Микроядро KasperskyOS – собственная разработка «Лаборатории Касперского». Как дизайн, так и реализация всех частей микроядра отвечают главной задаче – созданию безопасной операционной системы [19]. В KasperskyOS всего три системных вызова и только один интерфейс межпроцессного взаимодействия. Благодаря этому поверхность атаки минимальна. Микроядро KasperskyOS спроектировано так, чтобы по максимуму использовать возможности Kaspersky Security System. И ее микроядро – действительно «микро» (не более тысячи строк кода). В них втиснуты диспетчер процессов, механизм межпроцессного взаимодействия (IPC – inter-process communication), модуль контроля доступа KSS, который следит за механизмом IPC.
Таким образом, базовый принцип KasperskyOS аналогичен общему подходу любых микроядерных систем. Процессы взаимодействуют между собой и с функциями ядра системы, отправляя и получая IPC-сообщения. Микроядро предоставляет им эту возможность с помощью механизма IPC. В случае с KasperskyOS за этим механизмом следит KSS, которая для каждого IPC-сообщения выносит вердикт «можно» (allow) или «нельзя» (deny). При этом по умолчанию KSS реализует принцип default deny. То есть если программа по какой-то причине не реализует такую модель взаимодействия, то ни отправить, ни получить IPC-сообщения она не сможет. И останется в полной изоляции.
Вся остальная функциональность операционной системы, включая драйверы, файловые системы и сетевые стеки, вынесена в режим пользователя. Ядро KasperskyOS гарантирует полную изоляцию компонентов IT-системы. Единственный вид межпроцессных взаимодействий, предоставляемый ядром, – синхронный обмен сообщениями («запросом» и «ответом»). При этом каждое сообщение передается подсистеме Kaspersky Security System для проверки на соответствие заданной политике безопасности. Ядро доставит сообщение, только если это разрешено политикой. Таким образом, базовый принцип KasperskyOS идентичен общему подходу любых микроядерных систем. Процессы взаимодействуют между собой и с функциями ядра системы, отправляя и получая IPC-сообщения. Микроядро предоставляет им эту возможность с помощью механизма IPC (рис. 4). В случае KasperskyOS за этим механизмом следит KSS, которая для каждого IPC-сообщения выносит вердикт «можно» (allow) или «нельзя» (deny). При этом по умолчанию KSS реализует принцип default deny. Если программа по какой-то причине не реализует такую модель взаимодействия, то ни отправить, ни получить IPC-сообщения она не сможет и останется в полной изоляции. Следовательно, ни для вирусов, ни для вредоносного ПО, ни для «криворуко» написанного софта нет возможности нарушить вычислительный процесс.
Учитывая изложенные особенности построения микроядерной кибериммунной операционной системы KasperskyOS, ее модель графа состояний и переходов можно представить следующим образом (рис. 5).
Будем считать, что пользователь в работе может использовать свою программу, а также пользоваться услугами сервисов и сервера операционной системы KasperskyOS. Перечислим состояния и соответственно вероятности нахождения системы в этих состояниях.
P1 – вероятность того, что пользователь системы занят работой, в этом состоянии система исправна и работоспособна.
P2 – пользователь простаивает в связи с отказом со стороны ОС в использовании ее сервисов или сервера (причины: небезопасный код программы пользователя, неправильный запрос на услуги ОС и др.). В этом состоянии возможна перезагрузка программы и попытка дальнейшей работы. Операционная система исправна, поскольку она практически в силу небольшого объема кода (несколько десятков строк кода) практически безотказна. Для определенности примем наработку на отказ, равную 1 000 000 ч.
P3 – состояние отказа KOS по причине проявления ошибки в KSS или микроядре KOS. В этом случае возможна перезагрузка системы и дальнейшая работа пользователя.
Дальнейшие состояния и, соответственно, вероятности отображают работу компонентов KOS.
P4 – работа подсистемы Kaspersky Security System (KSS).
P5 – работа микроядра KOS.
P6 и P7 – работа сервисов и сервера системы, соответственно.
Перейдем к определению интенсивностей перехода между состояниями системы. Примем на основе данных статьи [2] интенсивность обращения клиента к услугам сервисов λ1 = 100 000 1 / c. В любом случае получение требуемой услуги происходит по схеме, приведенной на рис. 6. Как видно из этого рисунка, происходит некоторая задержка в обработке запроса клиента (дважды работает ядро и KSS), однако в нашей модели это можно не учитывать. Поэтому λ3 = λ4 = 100 000 1 / c. В потоке λ4 передается вердикт, определяющий возможность правильного выполнения запроса. Ответ «да» определяет интенсивность потока λ2, и, соответственно, ответ «нет» определяет интенсивность потока λ5. Будем считать, что с вероятностью, близкой к 1, например 0,9999999, будет получен ответ «да», в этом случае вероятность ответа «нет» равна 0,00000001. В этих условиях интенсивности потока
λ2 = λ1 ∙ 0,9999999 = 100 000 ∙ 0,9999999 = 9999999,9 1 / с, соответственно λ5 = 0,001 1 / с. Рассмотрим обращение клиента к услугам сервера. Пусть время выполнения сервиса KOS = 0,05 мс, а время выполнения драйвера сервера (печать на мониторе) – 5 мс [2]. Предположим, что на 10 000 запросов клиента приходится одно обращение к драйверу печати. Тогда среднее время обслуживания составит значение
0,05 ∙ 10 000 + 5
tср =—= 0,0505 мс = 0,0000505 с.
10 000
Таким образом, получаем, что интенсивность потока λ6 = 1 / 0,0000505 ≈ 19 802 1 / с. Интенсивности потоков λ8 и λ9 имеют такое же значение. Последний поток содержит значение вердикта. Ответ «да» определяет в этом случае интенсивность потока λ7, соответственно ответ «нет» определяет интенсивность потока λ10. Примем условие, что с вероятностью 0,999999 будет получен ответ «да», в этом случае вероятность ответа «нет» равна 0,000001. В этих условиях интенсивности потока λ7 = λ9 ∙ 0,999999 = 19 802 ∙ 0,999999 = 19 801,98 1 / с, соответственно λ10 = 0,02 1 / с.
Интенсивность потока λ11 определяется суммой интенсивностей λ3 и λ8 и, следовательно, равна 119 802 1 / c. Такую же интенсивность имеет поток вердиктов λ12. Интенсивность потоков λ13 и λ14 определяется только возможными программными ошибками в KOS. Пересчитывать количество таких ошибок, как это делалось выше, по статистическим данным в зависимости от числа строк программного кода не имеет смысла. Поверим заявлениям разработчиков KasperskyOS об отсутствии программных ошибок и для определенности будем считать, что наработка на отказ KOS равна 1 000 000 ч. На основании этого можно считать, что интенсивности отказов λ13 и λ14 составляют значение, равное 1 / 1000000 ч. Перевод в секунды дает значение λ13 = λ14 = 0,00000000028 1 / с. Что касается интенсивности потоков перезагрузки, примем ее равной значению в предыдущих моделях, то есть λ15 = λ16 = 0,0055 1 / c.
По полученному и размеченному графу состояний и переходов в соответствии с правилом, изложенным в разделе «Метод и ограничения, принятые при разработке моделей архитектур операционных систем», составляем систему линейных алгебраических уравнений, описывающих стационарный режим работы KOS:
(λ1 + λ6) ∙ P1 = λ2 ∙ P6 + λ7 ∙ P7 + λ16 ∙ P2;
λ16 ∙ P2 = λ5 ∙ P6 + λ10 ∙ P7;
λ15 ∙ P3 = λ13 ∙ P4 + λ14 ∙ P5;
(λ12 + λ13) ∙ P4 = λ11 ∙ P5;
(λ9 + λ4 + λ11 + λ14) ∙ P5 = λ8 ∙ P7 + λ3 ∙ P6 + λ12 ∙ P4 + λ15 ∙ P3;
(λ2 + λ5 + λ3) ∙ P6 = λ1 ∙ P1 + λ4 ∙ P5;
(λ7 + λ8 + λ10) ∙ P7 = λ6 ∙ P1 + λ9 ∙ P5;
P1 + P2 + P3 + P4 + P5 + P6 + P7 = 1. (6)
Аналогично, как и в предыдущих системах уравнений, исключаем из системы (6) пятое уравнение. Учитывая установленные выше значения коэффициентов при переменных и записав систему уравнений в матричной форме, удобной для решения средствами Excel, получим систему (6) в следующем виде:
119 802 ∙ P1 − 99 999,9 ∙ P6 − 19 801,98 ∙ P7 − 0,0055 ∙ P2 = 0;
0,0055 ∙ P2 − 0,1 ∙ P6 − 0,022 ∙ P7 = 0;
0,0055 ∙ P3 − 0,00000000028 ∙ P4 − 0,00000000028 ∙ P5 = 0;
100 000 ∙ P4 − 119 802 ∙ P5 = 0;
200 000 ∙ P6 − 100 000 ∙ P1 − 100 000 ∙ P5 = 0;
39 604 ∙ P7 − 19 802 ∙ P1 − 19 802 ∙ P5 = 0;
P1 + P2 + P3 + P4 + P5 + P6 + P7 = 1. (7)
Самым распространенным способом решения системы линейных уравнений в Excel является матричный метод. Он заключается в построении матрицы из коэффициентов уравнений и создании обратной матрицы. Матрицу заполняем числами, которые являются коэффициентами уравнения. Числа должны располагаться последовательно по порядку с учетом расположения корня, которому они соответствуют. Если в выражении отсутствует корень, то коэффициент считается равным нулю. Если коэффициент не обозначен, но соответствующий корень имеется, то считается, что коэффициент равен единице. Полученную таблицу считаем вектором . Далее необходимо получить матрицу, обратную существующей. Для этого можно воспользоваться функцией Excel МОБР. Окно аргументов этой функции и только одно поле – «Массив», в котором нужно указать адрес таблицы. При работе с массивами после завершения ввода формулы следует произвести набор сочетания клавиш Ctrl + Shift + Enter. После этого программа производит вычисления и на выходе в предварительно выделенной области мы имеем матрицу, обратную данной. Далее нужно умножить обратную матрицу на матрицу , которая состоит из одного столбца значений, расположенных после знака «равно» в выражениях. Для умножения таблиц в Excel есть функция МУМНОЖ. Активируется окно аргументов функции МУМНОЖ. В поле «Массив1» указываются координаты обратной матрицы. Аналогичное действие проводим для внесения координат в поле «Массив2», выделяя значения колонки . После набираем комбинацию клавиш Ctrl + Shift + Enter. В результате в предварительно выделенной ячейке отобразятся корни уравнения. Решение трех систем уравнений, составленных выше для рассмотренных моделей, показано на рис. 7.
Обсуждение результатов моделирования
Решение системы уравнений (3) дает следующие значения переменных: P1 = 0,090815456; P2 = 0,0000227039; P3 = 0,908154557; P4 = 0,001007284. Таким образом, вероятность того, что компьютерная система в установившемся состоянии исправно функционирует, равна сумме P2 + P3 + P4 = 0,909185. Такая низкая надежность ОС с многослойным ядром в нашем случае объясняется заданием в исходных данных большого количества программных ошибок в ядре и той части системы, которая работает в пользовательском режиме (300 000 ошибок). Вероятность нахождения системы в состоянии перезагрузки равна 0,090815456. Ситуация весьма похожа на начальные версии Linux и других операционных систем. В процессе устранения ошибок надежность системы, конечно, повысится, но все-таки не будет достаточно высокой. Радикальный путь – уменьшение ядра ОС.
Решение системы уравнений (6) дает следующие значения переменных: P1 = 0,003880570; P2 = 0,00384185; P3 = 0,952238435; P4 = 0,00190285; P5 = 0,3805695; P6 = 0,00000830. Таким образом, вероятность того, что компьютерная система в установившемся состоянии исправно функционирует, равна сумме P1 + P2 + P3 + P4 + P5 = 0,999534035. Вероятность того, что система в установившемся состоянии будет находиться на этапе перезагрузки, равна 0,00000830. Таким образом, результаты проведенных вычислений позволяют сделать вывод о значительно более высокой надежности работы микроядерной операционной системы по сравнению с операционной системой с большим многоуровневым модульным ядром. И в заключение рассмотрим решение системы уравнений (7). Оно дает следующие значения переменных: P1 = 0,106611549; P2 = 0,445830474; P3 = 0,0000000119298; P4 = 0,127722974; P5 = 0,106611721; P6 = 0,106611635; P7 = 0,106611635. Заметим, что в случае KasperskyOS, клиент может простаивать, получив вердикт deny (нет на рис. 5) на запрошенную услугу. В случае наших исходных данных вероятность такого простоя P2 = 0,445830474. Изменив интенсивности потоков λ2, λ7, которые определяют частоту появления вердикта «да» и λ2, λ7, которые определяют частоту появления вердикта «нет», можно получить требуемое значение вероятностей, определяющих работу и простой клиента. При этом операционная система работоспособна, что подтверждается низкой вероятностью ее отказа P3 = 0,0000000119298 в установившемся режиме. Конечно, в реальности (не в модели) вердикт определяется правильностью работы клиента при формировании запросов обращения к услугам сервисов и сервера.
* * *
При решении задач разработки, производства, выбора и эксплуатации программных и операционных систем, в частности, для исследования критических параметров, таких как надежность, безопасность, защищенность, часто требуется обратиться к методам моделирования, среди которых широкое применение получили методы имитационного, полунатурного и натурного моделирования. Традиционно под моделированием на ЭВМ понималось лишь имитационное моделирование (ИМ). Можно, однако, увидеть, что и при других видах моделирования компьютер может быть весьма полезен, за исключением разве физического моделирования, где компьютер тоже может использоваться, но, скорее, для целей управления процессом моделирования. При математическом моделировании выполнение одного из основных этапов – построение математических моделей по экспериментальным данным просто немыслимо без компьютера.
Имитационное моделирование представляет собой метод конструирования модели реальной системы и постановки экспериментов на этой модели с целью исследования ее поведения, либо оценивания различных стратегий, обеспечивающих функционирование данной системы. Этот метод может быть успешно использован для определения критических параметров архитектур операционных систем, их оценки, сравнения и выбора наиболее подходящей для конкретного применения. При этом необходимо создать структуру исследуемой системы и описать ее поведение с помощью состояний и моментов переходов между этими состояниями. Состояние системы в каждый момент времени можно определить как множество значений ее параметров в этот момент времени. Изменение значений параметров можно считать переходом в другое состояние. Внешняя среда задается посредством входных данных. При необходимости моделирования вероятностных систем и процессов в ИМ включается и статистическое моделирование.
Имитационное моделирование достаточно распространено при исследовании сложных систем благодаря ряду преимуществ. Благодаря ИМ на ранних стадиях предварительного проектирования систем можно быстро получить нужную информацию, пусть и с некоторыми допущениями, о возможном функционировании проектируемой системы. Можно исследовать особенности функционирования системы при любых условиях, в частности тех, которые не могут быть реализованы в натурных экспериментах. При этом параметры системы и окружающей среды можно варьировать в широких границах, воссоздавая произвольные, как реальные, так и гипотетические, ситуации. Главными недостатками метода машинной имитации являются довольно большие затраты времени и средств на построение адекватной модели, а также трудность и даже невозможность учета в модели некоторых важных особенностей реальной системы. По этим причинам машинную имитацию как численный машинный метод решения сложных задач целесообразно применять при следующих условиях:
непригодность или отсутствие аналитических методов решения задач;
полная уверенность в успешном создании имитационной модели, которая адекватно описывает исследуемую систему (процесс);
возможность использовать сам процесс построения имитационной модели для предварительного исследования моделируемой системы.
Натурный эксперимент для определения надежности и безопасности функционирования операционных систем различных архитектур практически невозможен в силу неприемлемых временных и финансовых затрат. Поэтому единственный путь решения этой проблемы – разработка простых и достаточно адекватных моделей.
Предложен подход к построению моделей архитектур операционных систем, основанный на теории марковских процессов, описываемых системами дифференциальных уравнений Колмогорова, в условиях принятия ограничений об абсолютной надежности аппаратуры, случайном характере и независимости отказов в программах без учета их восстановления и отсутствии параллельных процессов в работе модулей ОС. Этот подход может быть использован для начального исследования надежности функционирования конкретных архитектур операционных систем. Нельзя сказать, что такой подход не имеет недостатков. Один из них – ограничение числа возможных состояний в модели системы. При числе состояний более 8–10 усложняется решение систем линейных алгебраических уравнений. Повышение точности результатов моделирования в подобных моделях связано с уточнением исходных данных, которые определяют значения наработки на отказ модулей исследуемой операционной системы и интенсивности переходов исследуемой системы из одного состояния в другое. Для уточнения характеристик надежности модулей системы необходимо построение моделей изменения надежности при выявлении и устранении программных ошибок и соответствующая статистика разработчика операционных систем. Тем не менее, во многих случаях предложенный подход достаточно результативен.
Литература
Назаров С. В. Эффективность и оптимизация компьютерных систем: монография / 2‑е изд. М.: РУСАЙНС, 2021. 294 с.
Назаров С. В. Эффективность современных операционных систем // Современные информационные технологии и ИТ-образование. 2017. Т. 13 № 2. С. 9–24.
Назаров С. В., Вилкова Н. Н. Эффективность систем отображения информации коллективного пользования // Электросвязь. 2015. № 9. С. 29–33.
Назаров С. В., Вилкова Н. Н. Выбор оптимального варианта системы отображения информации коллективного пользования // Электросвязь. 2017. № 1. С. 60–65.
Таненбаум Э., Вудхалл А. Операционные системы. Разработка и реализация / 3‑е изд. СПб: Питер, 2007. 704 с.
Назаров С. В. Архитектура и проектирование программных систем: монография / 2‑е изд., перераб. и доп. М.: ИНФРА-М, 2016. 376 с.
Таненбаум Э., Хердер Дж., Бос Х. Построение надежных операционных систем, допускающих наличие ненадежных драйверов устройств. [Электронный ресурс]. URL: http://citforum.ru/operating_systems/microkernel_tanenbaum/
Назаров С. В., Широков А. И. Технологии многопользовательских операционных систем. М.: Изд. дом МИСиС, 2012. 296 с.
Назаров С. В., Вилкова Н. Н. Структурный рефакторинг многослойных программных систем // Информационные технологии и вычислительные системы. 2016. № 4. С. 13–23.
Tanenbaum Andrew S., Herder Jorrit N., Bos Herbert. Vrije Universiteit, Amsterdam. Can We Make Operating Systems Reliable and Secure? Computer (IEEE Computer Society, V. 39, No 5, May 2006).
Хердер Й., Бос Х., Таненбаум Э. Построение надежных операционных систем, допускающих наличие ненадежных драйверов устройств, 2006. [Электронный ресурс].
URL: http://citforum.ru/operating_systems/reliable_os/
Tanenbaum A. Introduction to MINIX 3 // OS News is Exploring the Future of Computing. 2006. [Электронный ресурс].
URL: http://www.osnews.com/story/15960/
Игнатов Р. MINIX 3 – реинкарнация? [Электронный ресурс]. URL: http://www.minix3.ru/articles/Ignatov-_minix_reincarnation.pdf
Таненбаум Э., Бос Э. Современные операционные системы // 4‑е изд. СПб: Питер, 2015. 1120 с.
Кельберт М. Я., Сухов Ю. М. Вероятность и статистика в примерах и задачах. Т. 2. Марковские цепи как отправная точка теории случайных процессов и их приложения. М.: МЦНМО, 2009. 476 с.
Кемени Дж., Снелл Дж. Конечные цепи Маркова. М.: Наука, 1970. 273 с.
Блинов А. Лаборатория Касперского – об основах кибериммунитета и концепции KasperskyOS. [Электронный ресурс].
URL: https://spbit.ru/news/Laboratoriya-Kasperskogo-ob-osnovakh-kiberimmuniteta
Архитектура KasperskyOS [Электронный ресурс]. URL: https://support.kaspersky.ru/help/KCE/1.1/ru-RU/overview_architecture.htm
Микроядро KasperskyOS. [Электронный ресурс]. URL: https://os.kaspersky.ru/technologies/microkernel/?ysclid=ll3ego7wh4870216945
С. Назаров, д. т. н., А. Барсуков, к. т. н.
В заключительной части статьи представлена модель операционной системы Касперского. На сегодняшний день KasperskyOS – это микроядерная частично POSIX-совместимая операционная система, не являющаяся системой общего назначения. Ее основное предназначение – разработка ИТ-продуктов для отраслей с повышенными требованиями к кибербезопасности, надежности и предсказуемости работы. Однако реальна возможность ее развития до операционной системы универсального применения. Цель статьи – показать, насколько кибериммунный принцип построения системы повышает надежность и безопасность создания операционных систем по сравнению с системами другой архитектуры.
Особенности архитектуры KasperskyOS
Прежде всего, надо отметить, что система полностью создана с чистого листа специалистами «Лаборатории Касперского», является оригинальной разработкой компании и зарегистрирована в реестре российского ПО как рекомендованная для приобретения отечественными организациями и государственными структурами [18]. Основой ОС служит надежное микроядро, которое допускает только строго определенный способ взаимодействия системных процессов и обмена данными, тем самым обеспечивая полноту контроля доступа. Будучи компактным, оно может портироваться на различные аппаратные платформы. KasperskyOS построена на базе концепции MILS (Multiple Independent Levels of Security – «множественные независимые уровни защиты/безопасности»), определяющей строгие принципы изоляции системных процессов и политик управления информационными потоками. Одним из наиболее важных компонентов ОС является модуль контроля доступа Kaspersky Security System (KSS), отслеживающий все межпроцессорные взаимодействия и исключающий доступ приложений к защищенным областям памяти с критически важными процессами и данными. KSS поддерживает широкий набор правил и политик доступа и может быть настроен в соответствии с конкретными требованиями заказчика. Любое действие, не предусмотренное политиками безопасности, запрещено по умолчанию. И это, пожалуй, самое важное отличие KasperskyOS от популярных сегодня операционных систем, в которых все, что не запрещено, по умолчанию разрешено.
Микроядро KasperskyOS – собственная разработка «Лаборатории Касперского». Как дизайн, так и реализация всех частей микроядра отвечают главной задаче – созданию безопасной операционной системы [19]. В KasperskyOS всего три системных вызова и только один интерфейс межпроцессного взаимодействия. Благодаря этому поверхность атаки минимальна. Микроядро KasperskyOS спроектировано так, чтобы по максимуму использовать возможности Kaspersky Security System. И ее микроядро – действительно «микро» (не более тысячи строк кода). В них втиснуты диспетчер процессов, механизм межпроцессного взаимодействия (IPC – inter-process communication), модуль контроля доступа KSS, который следит за механизмом IPC.
Таким образом, базовый принцип KasperskyOS аналогичен общему подходу любых микроядерных систем. Процессы взаимодействуют между собой и с функциями ядра системы, отправляя и получая IPC-сообщения. Микроядро предоставляет им эту возможность с помощью механизма IPC. В случае с KasperskyOS за этим механизмом следит KSS, которая для каждого IPC-сообщения выносит вердикт «можно» (allow) или «нельзя» (deny). При этом по умолчанию KSS реализует принцип default deny. То есть если программа по какой-то причине не реализует такую модель взаимодействия, то ни отправить, ни получить IPC-сообщения она не сможет. И останется в полной изоляции.
Вся остальная функциональность операционной системы, включая драйверы, файловые системы и сетевые стеки, вынесена в режим пользователя. Ядро KasperskyOS гарантирует полную изоляцию компонентов IT-системы. Единственный вид межпроцессных взаимодействий, предоставляемый ядром, – синхронный обмен сообщениями («запросом» и «ответом»). При этом каждое сообщение передается подсистеме Kaspersky Security System для проверки на соответствие заданной политике безопасности. Ядро доставит сообщение, только если это разрешено политикой. Таким образом, базовый принцип KasperskyOS идентичен общему подходу любых микроядерных систем. Процессы взаимодействуют между собой и с функциями ядра системы, отправляя и получая IPC-сообщения. Микроядро предоставляет им эту возможность с помощью механизма IPC (рис. 4). В случае KasperskyOS за этим механизмом следит KSS, которая для каждого IPC-сообщения выносит вердикт «можно» (allow) или «нельзя» (deny). При этом по умолчанию KSS реализует принцип default deny. Если программа по какой-то причине не реализует такую модель взаимодействия, то ни отправить, ни получить IPC-сообщения она не сможет и останется в полной изоляции. Следовательно, ни для вирусов, ни для вредоносного ПО, ни для «криворуко» написанного софта нет возможности нарушить вычислительный процесс.
Учитывая изложенные особенности построения микроядерной кибериммунной операционной системы KasperskyOS, ее модель графа состояний и переходов можно представить следующим образом (рис. 5).
Будем считать, что пользователь в работе может использовать свою программу, а также пользоваться услугами сервисов и сервера операционной системы KasperskyOS. Перечислим состояния и соответственно вероятности нахождения системы в этих состояниях.
P1 – вероятность того, что пользователь системы занят работой, в этом состоянии система исправна и работоспособна.
P2 – пользователь простаивает в связи с отказом со стороны ОС в использовании ее сервисов или сервера (причины: небезопасный код программы пользователя, неправильный запрос на услуги ОС и др.). В этом состоянии возможна перезагрузка программы и попытка дальнейшей работы. Операционная система исправна, поскольку она практически в силу небольшого объема кода (несколько десятков строк кода) практически безотказна. Для определенности примем наработку на отказ, равную 1 000 000 ч.
P3 – состояние отказа KOS по причине проявления ошибки в KSS или микроядре KOS. В этом случае возможна перезагрузка системы и дальнейшая работа пользователя.
Дальнейшие состояния и, соответственно, вероятности отображают работу компонентов KOS.
P4 – работа подсистемы Kaspersky Security System (KSS).
P5 – работа микроядра KOS.
P6 и P7 – работа сервисов и сервера системы, соответственно.
Перейдем к определению интенсивностей перехода между состояниями системы. Примем на основе данных статьи [2] интенсивность обращения клиента к услугам сервисов λ1 = 100 000 1 / c. В любом случае получение требуемой услуги происходит по схеме, приведенной на рис. 6. Как видно из этого рисунка, происходит некоторая задержка в обработке запроса клиента (дважды работает ядро и KSS), однако в нашей модели это можно не учитывать. Поэтому λ3 = λ4 = 100 000 1 / c. В потоке λ4 передается вердикт, определяющий возможность правильного выполнения запроса. Ответ «да» определяет интенсивность потока λ2, и, соответственно, ответ «нет» определяет интенсивность потока λ5. Будем считать, что с вероятностью, близкой к 1, например 0,9999999, будет получен ответ «да», в этом случае вероятность ответа «нет» равна 0,00000001. В этих условиях интенсивности потока
λ2 = λ1 ∙ 0,9999999 = 100 000 ∙ 0,9999999 = 9999999,9 1 / с, соответственно λ5 = 0,001 1 / с. Рассмотрим обращение клиента к услугам сервера. Пусть время выполнения сервиса KOS = 0,05 мс, а время выполнения драйвера сервера (печать на мониторе) – 5 мс [2]. Предположим, что на 10 000 запросов клиента приходится одно обращение к драйверу печати. Тогда среднее время обслуживания составит значение
0,05 ∙ 10 000 + 5
tср =—= 0,0505 мс = 0,0000505 с.
10 000
Таким образом, получаем, что интенсивность потока λ6 = 1 / 0,0000505 ≈ 19 802 1 / с. Интенсивности потоков λ8 и λ9 имеют такое же значение. Последний поток содержит значение вердикта. Ответ «да» определяет в этом случае интенсивность потока λ7, соответственно ответ «нет» определяет интенсивность потока λ10. Примем условие, что с вероятностью 0,999999 будет получен ответ «да», в этом случае вероятность ответа «нет» равна 0,000001. В этих условиях интенсивности потока λ7 = λ9 ∙ 0,999999 = 19 802 ∙ 0,999999 = 19 801,98 1 / с, соответственно λ10 = 0,02 1 / с.
Интенсивность потока λ11 определяется суммой интенсивностей λ3 и λ8 и, следовательно, равна 119 802 1 / c. Такую же интенсивность имеет поток вердиктов λ12. Интенсивность потоков λ13 и λ14 определяется только возможными программными ошибками в KOS. Пересчитывать количество таких ошибок, как это делалось выше, по статистическим данным в зависимости от числа строк программного кода не имеет смысла. Поверим заявлениям разработчиков KasperskyOS об отсутствии программных ошибок и для определенности будем считать, что наработка на отказ KOS равна 1 000 000 ч. На основании этого можно считать, что интенсивности отказов λ13 и λ14 составляют значение, равное 1 / 1000000 ч. Перевод в секунды дает значение λ13 = λ14 = 0,00000000028 1 / с. Что касается интенсивности потоков перезагрузки, примем ее равной значению в предыдущих моделях, то есть λ15 = λ16 = 0,0055 1 / c.
По полученному и размеченному графу состояний и переходов в соответствии с правилом, изложенным в разделе «Метод и ограничения, принятые при разработке моделей архитектур операционных систем», составляем систему линейных алгебраических уравнений, описывающих стационарный режим работы KOS:
(λ1 + λ6) ∙ P1 = λ2 ∙ P6 + λ7 ∙ P7 + λ16 ∙ P2;
λ16 ∙ P2 = λ5 ∙ P6 + λ10 ∙ P7;
λ15 ∙ P3 = λ13 ∙ P4 + λ14 ∙ P5;
(λ12 + λ13) ∙ P4 = λ11 ∙ P5;
(λ9 + λ4 + λ11 + λ14) ∙ P5 = λ8 ∙ P7 + λ3 ∙ P6 + λ12 ∙ P4 + λ15 ∙ P3;
(λ2 + λ5 + λ3) ∙ P6 = λ1 ∙ P1 + λ4 ∙ P5;
(λ7 + λ8 + λ10) ∙ P7 = λ6 ∙ P1 + λ9 ∙ P5;
P1 + P2 + P3 + P4 + P5 + P6 + P7 = 1. (6)
Аналогично, как и в предыдущих системах уравнений, исключаем из системы (6) пятое уравнение. Учитывая установленные выше значения коэффициентов при переменных и записав систему уравнений в матричной форме, удобной для решения средствами Excel, получим систему (6) в следующем виде:
119 802 ∙ P1 − 99 999,9 ∙ P6 − 19 801,98 ∙ P7 − 0,0055 ∙ P2 = 0;
0,0055 ∙ P2 − 0,1 ∙ P6 − 0,022 ∙ P7 = 0;
0,0055 ∙ P3 − 0,00000000028 ∙ P4 − 0,00000000028 ∙ P5 = 0;
100 000 ∙ P4 − 119 802 ∙ P5 = 0;
200 000 ∙ P6 − 100 000 ∙ P1 − 100 000 ∙ P5 = 0;
39 604 ∙ P7 − 19 802 ∙ P1 − 19 802 ∙ P5 = 0;
P1 + P2 + P3 + P4 + P5 + P6 + P7 = 1. (7)
Самым распространенным способом решения системы линейных уравнений в Excel является матричный метод. Он заключается в построении матрицы из коэффициентов уравнений и создании обратной матрицы. Матрицу заполняем числами, которые являются коэффициентами уравнения. Числа должны располагаться последовательно по порядку с учетом расположения корня, которому они соответствуют. Если в выражении отсутствует корень, то коэффициент считается равным нулю. Если коэффициент не обозначен, но соответствующий корень имеется, то считается, что коэффициент равен единице. Полученную таблицу считаем вектором . Далее необходимо получить матрицу, обратную существующей. Для этого можно воспользоваться функцией Excel МОБР. Окно аргументов этой функции и только одно поле – «Массив», в котором нужно указать адрес таблицы. При работе с массивами после завершения ввода формулы следует произвести набор сочетания клавиш Ctrl + Shift + Enter. После этого программа производит вычисления и на выходе в предварительно выделенной области мы имеем матрицу, обратную данной. Далее нужно умножить обратную матрицу на матрицу , которая состоит из одного столбца значений, расположенных после знака «равно» в выражениях. Для умножения таблиц в Excel есть функция МУМНОЖ. Активируется окно аргументов функции МУМНОЖ. В поле «Массив1» указываются координаты обратной матрицы. Аналогичное действие проводим для внесения координат в поле «Массив2», выделяя значения колонки . После набираем комбинацию клавиш Ctrl + Shift + Enter. В результате в предварительно выделенной ячейке отобразятся корни уравнения. Решение трех систем уравнений, составленных выше для рассмотренных моделей, показано на рис. 7.
Обсуждение результатов моделирования
Решение системы уравнений (3) дает следующие значения переменных: P1 = 0,090815456; P2 = 0,0000227039; P3 = 0,908154557; P4 = 0,001007284. Таким образом, вероятность того, что компьютерная система в установившемся состоянии исправно функционирует, равна сумме P2 + P3 + P4 = 0,909185. Такая низкая надежность ОС с многослойным ядром в нашем случае объясняется заданием в исходных данных большого количества программных ошибок в ядре и той части системы, которая работает в пользовательском режиме (300 000 ошибок). Вероятность нахождения системы в состоянии перезагрузки равна 0,090815456. Ситуация весьма похожа на начальные версии Linux и других операционных систем. В процессе устранения ошибок надежность системы, конечно, повысится, но все-таки не будет достаточно высокой. Радикальный путь – уменьшение ядра ОС.
Решение системы уравнений (6) дает следующие значения переменных: P1 = 0,003880570; P2 = 0,00384185; P3 = 0,952238435; P4 = 0,00190285; P5 = 0,3805695; P6 = 0,00000830. Таким образом, вероятность того, что компьютерная система в установившемся состоянии исправно функционирует, равна сумме P1 + P2 + P3 + P4 + P5 = 0,999534035. Вероятность того, что система в установившемся состоянии будет находиться на этапе перезагрузки, равна 0,00000830. Таким образом, результаты проведенных вычислений позволяют сделать вывод о значительно более высокой надежности работы микроядерной операционной системы по сравнению с операционной системой с большим многоуровневым модульным ядром. И в заключение рассмотрим решение системы уравнений (7). Оно дает следующие значения переменных: P1 = 0,106611549; P2 = 0,445830474; P3 = 0,0000000119298; P4 = 0,127722974; P5 = 0,106611721; P6 = 0,106611635; P7 = 0,106611635. Заметим, что в случае KasperskyOS, клиент может простаивать, получив вердикт deny (нет на рис. 5) на запрошенную услугу. В случае наших исходных данных вероятность такого простоя P2 = 0,445830474. Изменив интенсивности потоков λ2, λ7, которые определяют частоту появления вердикта «да» и λ2, λ7, которые определяют частоту появления вердикта «нет», можно получить требуемое значение вероятностей, определяющих работу и простой клиента. При этом операционная система работоспособна, что подтверждается низкой вероятностью ее отказа P3 = 0,0000000119298 в установившемся режиме. Конечно, в реальности (не в модели) вердикт определяется правильностью работы клиента при формировании запросов обращения к услугам сервисов и сервера.
* * *
При решении задач разработки, производства, выбора и эксплуатации программных и операционных систем, в частности, для исследования критических параметров, таких как надежность, безопасность, защищенность, часто требуется обратиться к методам моделирования, среди которых широкое применение получили методы имитационного, полунатурного и натурного моделирования. Традиционно под моделированием на ЭВМ понималось лишь имитационное моделирование (ИМ). Можно, однако, увидеть, что и при других видах моделирования компьютер может быть весьма полезен, за исключением разве физического моделирования, где компьютер тоже может использоваться, но, скорее, для целей управления процессом моделирования. При математическом моделировании выполнение одного из основных этапов – построение математических моделей по экспериментальным данным просто немыслимо без компьютера.
Имитационное моделирование представляет собой метод конструирования модели реальной системы и постановки экспериментов на этой модели с целью исследования ее поведения, либо оценивания различных стратегий, обеспечивающих функционирование данной системы. Этот метод может быть успешно использован для определения критических параметров архитектур операционных систем, их оценки, сравнения и выбора наиболее подходящей для конкретного применения. При этом необходимо создать структуру исследуемой системы и описать ее поведение с помощью состояний и моментов переходов между этими состояниями. Состояние системы в каждый момент времени можно определить как множество значений ее параметров в этот момент времени. Изменение значений параметров можно считать переходом в другое состояние. Внешняя среда задается посредством входных данных. При необходимости моделирования вероятностных систем и процессов в ИМ включается и статистическое моделирование.
Имитационное моделирование достаточно распространено при исследовании сложных систем благодаря ряду преимуществ. Благодаря ИМ на ранних стадиях предварительного проектирования систем можно быстро получить нужную информацию, пусть и с некоторыми допущениями, о возможном функционировании проектируемой системы. Можно исследовать особенности функционирования системы при любых условиях, в частности тех, которые не могут быть реализованы в натурных экспериментах. При этом параметры системы и окружающей среды можно варьировать в широких границах, воссоздавая произвольные, как реальные, так и гипотетические, ситуации. Главными недостатками метода машинной имитации являются довольно большие затраты времени и средств на построение адекватной модели, а также трудность и даже невозможность учета в модели некоторых важных особенностей реальной системы. По этим причинам машинную имитацию как численный машинный метод решения сложных задач целесообразно применять при следующих условиях:
непригодность или отсутствие аналитических методов решения задач;
полная уверенность в успешном создании имитационной модели, которая адекватно описывает исследуемую систему (процесс);
возможность использовать сам процесс построения имитационной модели для предварительного исследования моделируемой системы.
Натурный эксперимент для определения надежности и безопасности функционирования операционных систем различных архитектур практически невозможен в силу неприемлемых временных и финансовых затрат. Поэтому единственный путь решения этой проблемы – разработка простых и достаточно адекватных моделей.
Предложен подход к построению моделей архитектур операционных систем, основанный на теории марковских процессов, описываемых системами дифференциальных уравнений Колмогорова, в условиях принятия ограничений об абсолютной надежности аппаратуры, случайном характере и независимости отказов в программах без учета их восстановления и отсутствии параллельных процессов в работе модулей ОС. Этот подход может быть использован для начального исследования надежности функционирования конкретных архитектур операционных систем. Нельзя сказать, что такой подход не имеет недостатков. Один из них – ограничение числа возможных состояний в модели системы. При числе состояний более 8–10 усложняется решение систем линейных алгебраических уравнений. Повышение точности результатов моделирования в подобных моделях связано с уточнением исходных данных, которые определяют значения наработки на отказ модулей исследуемой операционной системы и интенсивности переходов исследуемой системы из одного состояния в другое. Для уточнения характеристик надежности модулей системы необходимо построение моделей изменения надежности при выявлении и устранении программных ошибок и соответствующая статистика разработчика операционных систем. Тем не менее, во многих случаях предложенный подход достаточно результативен.
Литература
Назаров С. В. Эффективность и оптимизация компьютерных систем: монография / 2‑е изд. М.: РУСАЙНС, 2021. 294 с.
Назаров С. В. Эффективность современных операционных систем // Современные информационные технологии и ИТ-образование. 2017. Т. 13 № 2. С. 9–24.
Назаров С. В., Вилкова Н. Н. Эффективность систем отображения информации коллективного пользования // Электросвязь. 2015. № 9. С. 29–33.
Назаров С. В., Вилкова Н. Н. Выбор оптимального варианта системы отображения информации коллективного пользования // Электросвязь. 2017. № 1. С. 60–65.
Таненбаум Э., Вудхалл А. Операционные системы. Разработка и реализация / 3‑е изд. СПб: Питер, 2007. 704 с.
Назаров С. В. Архитектура и проектирование программных систем: монография / 2‑е изд., перераб. и доп. М.: ИНФРА-М, 2016. 376 с.
Таненбаум Э., Хердер Дж., Бос Х. Построение надежных операционных систем, допускающих наличие ненадежных драйверов устройств. [Электронный ресурс]. URL: http://citforum.ru/operating_systems/microkernel_tanenbaum/
Назаров С. В., Широков А. И. Технологии многопользовательских операционных систем. М.: Изд. дом МИСиС, 2012. 296 с.
Назаров С. В., Вилкова Н. Н. Структурный рефакторинг многослойных программных систем // Информационные технологии и вычислительные системы. 2016. № 4. С. 13–23.
Tanenbaum Andrew S., Herder Jorrit N., Bos Herbert. Vrije Universiteit, Amsterdam. Can We Make Operating Systems Reliable and Secure? Computer (IEEE Computer Society, V. 39, No 5, May 2006).
Хердер Й., Бос Х., Таненбаум Э. Построение надежных операционных систем, допускающих наличие ненадежных драйверов устройств, 2006. [Электронный ресурс].
URL: http://citforum.ru/operating_systems/reliable_os/
Tanenbaum A. Introduction to MINIX 3 // OS News is Exploring the Future of Computing. 2006. [Электронный ресурс].
URL: http://www.osnews.com/story/15960/
Игнатов Р. MINIX 3 – реинкарнация? [Электронный ресурс]. URL: http://www.minix3.ru/articles/Ignatov-_minix_reincarnation.pdf
Таненбаум Э., Бос Э. Современные операционные системы // 4‑е изд. СПб: Питер, 2015. 1120 с.
Кельберт М. Я., Сухов Ю. М. Вероятность и статистика в примерах и задачах. Т. 2. Марковские цепи как отправная точка теории случайных процессов и их приложения. М.: МЦНМО, 2009. 476 с.
Кемени Дж., Снелл Дж. Конечные цепи Маркова. М.: Наука, 1970. 273 с.
Блинов А. Лаборатория Касперского – об основах кибериммунитета и концепции KasperskyOS. [Электронный ресурс].
URL: https://spbit.ru/news/Laboratoriya-Kasperskogo-ob-osnovakh-kiberimmuniteta
Архитектура KasperskyOS [Электронный ресурс]. URL: https://support.kaspersky.ru/help/KCE/1.1/ru-RU/overview_architecture.htm
Микроядро KasperskyOS. [Электронный ресурс]. URL: https://os.kaspersky.ru/technologies/microkernel/?ysclid=ll3ego7wh4870216945
Отзывы читателей
