Андрей Духвалов, руководитель управления перспективных технологий «Лаборатории Касперского».
В софтверном бизнесе – около 30 лет. Большую часть своей профессиональной деятельности занимался разработкой разнообразного ПО в качестве программиста,
ведущего инженера, архитектора, лидера проекта. Участвовал в различных проектах по созданию программных продуктов системного и прикладного уровня. Последние 15 лет Андрей разрабатывает ПО в области информационной безопасности. В настоящее время возглавляет
подразделение ЛК, занимающееся исследованием новейших технологий.
KasperskyOS — это безопасная операционная система, предназначенная для встраиваемых систем, которые подключены к интернету и которым предъявляются специфические требования информационной безопасности. Задача KasperskyOS — защищать программное обеспечение и данные системы от последствий действий вредоносного кода и атак хакеров, таких как недекларируемое поведение любой из частей системы, потеря, уничтожение или модификация конфиденциальной или приватной информации, падение производительности или отказ в работе. В дополнение к этому KasperskyOS позволяет снизить влияние ошибок в программном обеспечении на работу системы.
Работа над KasperskyOS началась в 2002 году с идеи о том, что требуется полноценная защищенная от злоумышленников среда. На тот момент security-индустрии в целом отводилась второстепенная роль – сначала «плохие» ребята находили какую-нибудь дырку в системе, а потом все бросались ее закрывать. Всегда инициатива принадлежала этим самым «плохим» парням. А что, если сделать операционную среду, в которой будет невозможно каким-либо программам выполнять посторонние функции? Например, сегодня никто из разработчиков ПО и оборудования смартфона не может гарантированно сказать, что при выполнении умножении 2x2 на калькуляторе мобильного устройства оно не будет параллельно отправлять SMS или связываться с сервером. В такой среде по умолчанию должно быть запрещено все, что заранее не было разрешено.
Реализовать такую защищенную среду можно только на уровне операционной системы -- среда должна быть организована таким образом, чтобы даже при обнаружении «дыр» злоумышленник не смог ими воспользоваться. Иными словами, программы внутри такой системы при любых условиях будут делать только то, для чего они предназначены в соответствии с заранее прописанными ограничениями. А значит, приложения будут лучше защищены не только от воздействий извне, но и друг от друга. Существующие ОС изначально создавались для других целей и инструменты информационной безопасности добавляются в них в виде дополнительных модулей и функций, что не решает фундаментальной проблемы уязвимости.
KasperskyOS — микроядерная система, в ядре которой прописаны диспетчер процессов, механизм межпроцессного взаимодействия (inter-process communication, IPC) и система мониторинга обращений (reference monitor), получившая название Kaspersky Security System (KSS). Все остальные процессы и компоненты: управление памятью и периферийными устройствами, драйверы файловых систем, и т.п. в данном случае работали ли бы против концепции безопасности, поэтому от них было решено отказаться.
Процессы в ОС взаимодействуют между собой и с функциями ядра, отправляя и получая IPC-сообщения. Для каждого из этих сообщений KSS решает, разрешить его (allow) или запретить (deny). По умолчанию, напомним, применяется принцип default deny -- если KSS не обнаруживает четкого правила, разрешающего то или иное действие, оно запрещается.
Рис. 1.Архитектура KasperskyOS
При написании приложений для Kaspersky OS используется особый подход, называемый «компонентной моделью», в основе которой лежит понятие «сущности» (entity). Сущностью может быть как целая программа, так и ее отдельная функция. В общем случае программа включает в себя набор компонентов, каждый из которых содержит внутрикомпонентную сущность. Таким образом, выполнение программы в Kaspersky OS превращается в IPC-переписку сущностей.
Чтобы участвовать в переписке, сущность обязана удовлетворять одному важному условию -- в ней должен присутствовать код интерфейса доступа к механизму микроядра IPC. Важно отметить, что разработчик не участвует в создании этой части кода – код автоматически генерируется из описания интерфейса на языке IDL (Interface Definition Language) — С++-подобном языке спецификации интерфейсов в распределительных системах. Cтрогая типизация IDL позволяет проводить формальную верификацию корректности взаимодействия одной сущности с другой и проверять код на безошибочность.
С помощью кода интерфейса формируются две функции: Proxy для клиентских приложений и Dispatch — для серверных. Клиентское приложение вызывает функцию серверного приложения или ядра системы, передает параметры функции Proxy и сериализует их (упаковывает в формат IPC-сообщения). Затем приложение вызывает транспортную функцию IPC в микроядре, передает ей созданное IPC-сообщение, ждет ответного IPC-сообщения, десериализует его и передает сделавшему вызов базовому коду клиента. Функция Dispatch делает обратное: получает IPC-сообщение, десериализует его (распаковывает параметры для вызываемой функции), передает параметры базовому коду связанного с интерфейсом сервиса и, наконец, сериализует результат в IPC-сообщение.
Если сущность содержит много компонентов, каждый из которых состоит из разных функций, то они описываются на языке CDL (Component Definition Language). Специально разработанный компилятор Nk генерирует единый в рамках компонента код с интерфейсом, который на самом деле представляет собой совокупность Dispatch-интерфейсов всех входящих функций.
Для многокомпонентных сущностей имеется язык EDL (Entity Definition Language) описания всех компонентов и отдельных функций с собственными Dispatch-интерфейсами. При компилировании EDL-файла формируется общий код сущности с единым Dispatch-интерфейсом. Найти адресата для него можно по уникальному идентификатору Runtime Interface ID (RIID), который генерируется на этапе компиляции EDL-описания сущности. Такая вложенность типизированных спецификаций позволяет создавать сложные программы, в которых каждая функция будет снабжена собственным Proxy- или Dispatch-интерфейсом.
IPC-взаимодействие — это дело двух сущностей и этим напоминает технологию P2P, однако в отличие от нее осуществляется по принципу рандеву. Чтобы рандеву состоялось, создается канал обмена IPC-сообщениями путем выделения сущностям глобальных системных указателей (хендлов, handle, идентифицирующих сущности отправителя и получателя. Как только сущности становятся владельцами своих хендлов, открывается IPC-канал. Каждая сущность знает только о выделенном ей хендле, а о паре хендлов знает только механизм IPC. Формирование IPC-канала называется «спариванием хендлов» (handles pairing). После спаривания посторонний участник не может вклиниться в диалог, а канал остается открытым до тех пор, пока сущности остаются владельцами хендлов. Модель IPC-взаимодействия на основе спаренных хендлов запатентована «Лабораторией Касперского».
Никто не может вклиниться в IPС-диалог, однако система KSS может просматривать проходящие по каналу сообщения. KSS состоит из двух основных частей:
– модуль Security Server, принимающий решение о вердикте на основе политики безопасности;
– структура Decision Cache, хранящая вердикты по отдельным политикам для повышения производительности перлюстрации.
Рис. 2. Принцип работы Kaspersky Security System
Решение разрешать или запрещать IPC-взаимодействие принимается в соответствии с политикой безопасности, которая зависит от свойств и целей системы. Политика безопасности описывается с помощью формального аппарата, например, в терминах темпоральных логик. Чтобы связать конкретные действия сущностей с конкретными политиками безопасности, был разработан декларативный язык конфигураций безопасности CFG. Конфигурация безопасности на этом языке в сочетании с IDL-описанием интерфейса сущности позволяют компилятору Nk сгенерировать структуру данных Gate с уникальным идентификатором SID (Security ID). Эта структура связывает сущность с политикой безопасности. Если у сущности нет структуры Gate, то к ней применяется принцип default deny.
Багаж унаследованных приложений иногда не позволяет полностью заменить имеющуюся у пользователей ОС на KasperskyOS, поэтому в некоторых случаях достаточно внедрить KSS в уже существующую операционную систему.
Имеется два способа создания приложений, работающих под управлением KasperskyOS:
- перенос существующих приложений, использующих POSIX API. После портирования процессы, происходящие внутри такого ПО, не будут контролироваться ОС, однако его внешние связи буду безопасными;
- разработка новых приложения. С точки зрения обеспечения безопасности, это лучший вариант – функции будут проверены системой и при написании кода программисту не надо задумываться о безопасности. С точки зрения программиста писать для KasperskyOS ничуть не сложнее, чем писать для, скажем, Linux. Тот же API. Дополнительный инструментарий, поставляемый в KasperskyOS SDK и описанный в статье, только помогает разрабатывать программное обеспечение быстрее и безопаснее. Отличие состоит в двух моментах. Во-первых, разработчику не надо задумываться о функционале безопасности и во-вторых, на этапе разработки архитектуры необходимо продумать разбиение на домены безопасности (сущности) и разработать политику безопасности, которая будет реализована впоследствии параллельно с разработкой функциональной части приложения.
Говорят, что писать не безопасный код легко и дешево. С KasperskyOS писать безопасный код становится легко и дешево
***
Система KasperskyOS предназначена для индустриальных сетей (PLC-контроллеры, SCADA-системы), телекоммуникационного оборудования, «умных» автомобилей и устройств Интернета вещей в целом. В планах развитие этих направлений и разработка дополнительных функциональных моделей, облегчающих жизнь клиентов и разработчиков. Другими словами, есть прекрасный скелет, теперь самое время на этот скелет наложить такие же отличные мышцы!
Уважаемые коллеги! Для прохода в здание РАН просим принести документ, удостоверяющий личность.
