CC BY
53
НАУЧНО-ТЕХНИЧЕСКИИ ВЕСТНИК ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ, МЕХАНИКИ И ОПТИКИ май-июнь 2015 Том 15 № 3 ISSN 2226-1494 http://ntv.ifmo.ru/
SCIENTIFIC AND TECHNICAL JOURNAL OF INFORMATION TECHNOLOGIES, MECHANICS AND OPTICS
May-June 2015
Vol. 15 No 3 ISSN 2226-1494
http://ntv.ifmo.ru/en
УДК 004.056.53
АБСТРАКТНЫЕ МОДЕЛИ ВИРТУАЛИЗАЦИИ СИСТЕМЫ М.Г. Ковешников", К.А. Щеглов\ А.Ю. Щегловь
a Университет ИТМО, Санкт-Петербург, 197101, Российская Федерация
ь ООО «НПП «Информационные технологии в бизнесе», Санкт-Петербург, 194044, Российская Федерация Адрес для переписки: info@npp-itb.spb.ru Информация о статье
Поступила в редакцию 08.04.15, принята к печати 17.04.15
doi:10.17586/2226-1494-2015-15-3-483-492
Язык статьи - русский
Ссылка для цитирования: Ковешников М.Г., Щеглов К.А., Щеглов А.Ю. Абстрактные модели виртуализации системы // Научно-технический вестник информационных технологий, механики и оптики. 2015. Т. 15. № 3. C. 483-492.
Аннотация
Представлены результаты исследования защиты системных объектов - системных файлов и файлов пользовательских конфигураций системы и приложений - от несанкционированного к ним доступа, в том числе с целью реализации защиты от атак на отказ в обслуживании. Предложен метод и разработаны абстрактные модели виртуализации системы, на которых исследованы сценарии атак для различных режимов виртуализации. Дана оценка эффективности технологии виртуализации системных средств. Предлагаемая технология основана на реализации перенаправлений запросов доступа к разделяемым между субъектами системным объектам. Смоделированы режимы полной и частичной виртуализации системы: в режиме полной виртуализации создаются копии всех системных объектов доступа, на которые перенаправляются запросы субъектов, включая соответствующие объекты приложений; в режиме частичной виртуализации создаются соответствующие копии лишь части системы, например, только системные объекты приложений. Применительно к различным сценариям атак оценена эффективность альтернативных решений. Рассмотрено запатентованное апробированное техническое решение, реализующее метод виртуализации системы для операционных систем семейства Microsoft Windows, на примере которого показаны возможности и простота администрирования соответствующим образом построенных средств защиты системных объектов. Подтверждена практическая значимость предложенного метода защиты. Ключевые слова
информационная безопасность, системный объект, защита, отказ в обслуживании, виртуализация системного средства, сценарий атаки, абстрактная модель.
ABSTRACT MODELS FOR SYSTEM VIRTUALIZATION M.G. Koveshnikov", K. A. Shcheglovb, A. Yu. Shcheglovb
a ITMO University, Saint Petersburg, 197101, Russian Federation
ь OOO «Scientific Production Enterprise "Information technologies in business», Saint Petersburg, 194044, Russian Federation
Corresponding author: info@npp-itb.spb.ru Article info
Received 08.04.15, accepted 17.04.15 doi:10.17586/2226-1494-2015-15-3-483-492 Article in Russian
For citation: Koveshnikov M.G., Shcheglov K.A., Shcheglov A.Yu. Abstract models for system virtualization. Scientific and Technical Journal of Information Technologies, Mechanics and Optics, 2015, vol.15, no. 3, pp. 483-492.
Abstract
The paper is dedicated to issues of system objects securing (system files and user system or application configuration files) against unauthorized access including denial of service attacks. We have suggested the method and developed abstract system virtualization models, which are used to research attack scenarios for different virtualization modes. Estimation for system tools virtualization technology effectiveness is given. Suggested technology is based on redirection of access requests to system objects shared among access subjects. Whole and partial system virtualization modes have been modeled. The difference between them is the following: in the whole virtualization mode all copies of access system objects are created whereon subjects' requests are redirected including corresponding application objects; in the partial virtualization mode corresponding copies are created only for part of a system, for example, only system objects for applications. Alternative solutions effectiveness is valued relating to different attack scenarios. We consider proprietary and approved technical solution which implements system virtualization method for Microsoft Windows OS family. Administrative simplicity and capabilities of correspondingly designed system objects security tools are illustrated on this example. Practical significance of the suggested security method has been confirmed. Keywords
informational security, system object, security, denial of service, system tool virtualization, attack scenario, abstract model.
Введение
Для современных корпоративных информационных систем характерна одновременная работа на различных уровнях конфиденциальности. Как правило, один и тот же сотрудник на одном и том же компьютере должен обрабатывать информацию различных уровней конфиденциальности, в различных режимах (сессиях) [1] с различными требованиями к защите информации. Для обеспечения необходимого уровня информационной безопасности в этом случае возможны два решения:
- изолирование сессий обработки информации на защищаемом компьютере, где сессия определяется учетной записью, что является единственно возможным корректным решением для сессионного контроля доступа [1];
- организация такого режима работы приложений, который бы минимизировал риск потерь от успешной атаки на критичную сессию (менее защищенную, например, созданную для обработки открытой информации, в том числе предполагающую неконтролируемый доступ к ресурсам Интернет) или на критичное приложение.
Для изолирования сессий по данным (в том числе с целью предотвращения утечек конфиденциальной информации в результате реализации на том же компьютере незащищенной обработки открытой информации) успешно может применяться технология контроля доступа к создаваемым объектам - как к создаваемым файлам, так и к данным, помещаемым в буфер обмена [2, 3]. Такая технология основана на реализации запатентованного технического решения [4].
С системными файловыми объектами ситуация значительно сложнее, хотя задача защиты от отказа в обслуживании, связанная с несанкционированным удалением или модификацией системных файлов и файлов пользовательских конфигураций, не менее актуальна. Реализация разграничительной политики доступа к системным объектам путем настройки прав доступа пользователей к системным файлам и к файлам пользовательских конфигураций представляет собою крайне трудоемкую практическую задачу [5]. С этой целью можно использовать технологию виртуализации машин, предполагающую использование избыточной вычислительной мощности серверов [6-8]. Эффект защиты в данном случае достигается за счет того, что для каждого пользователя может быть создана своя виртуальная машина [9, 10]. Однако эта технология крайне избыточна и существенно загружает вычислительные ресурсы. Кроме того, ее прямое назначение - совсем иное, а решение задачи защиты в данном случае можно рассматривать лишь как некий дополнительный эффект.
Для решения задачи защиты в настоящей работе предлагается технология виртуализации системных средств.
Технология виртуализации системных средств
Под виртуальной системой будем понимать систему, состоящую из копий системных файлов, создаваемую для субъекта доступа, сессия которого изолируется, на которую перенаправляются запросы доступа субъекта к оригинальной (базовой) системе.
Сначала рассмотрим предлагаемую технологию в общем случае. Пусть исходно на системном диске (C:) установлена операционная система (ОС) и приложения, и пусть в системе заведены два интерактивных пользователя User 1 и User 2, сессии которых требуется разделить.
Создадим копии системного диска C: на дисках D: и E: Для этого скопируем соответствующие системные и скрытые файлы, что достаточно просто сделать. С учетом выполненной процедуры копирования далее будем говорить, что на диске C: установлена базовая система, на дисках D: и E: - созданные нами виртуальные системы.
Заметим, что виртуальные системы не обязательно создавать на отдельных дисках, можно их создать в отдельных каталогах того же диска C:.
Теперь зададим правила перенаправления запросов к файловым объектам. Для пользователя User 1 это будет правило перенаправления доступа к диску C: на диск D:, для User 2 - правило перенаправления доступа к диску C: на диск E:. Реализуя разграничительную политику доступа к файловым объектам, запретим пользователю User 1 доступ к диску E:, а пользователю User 2 - к диску D:. В результате этого получим схему виртуализации системы, приведенную на рис. 1.
Рассмотрим работу системы. С базовой системой может взаимодействовать только системный пользователь, запросы к базовой системе интерактивных пользователей User 1 и User 2 перенаправляются к соответствующим виртуальным системам. Таким образом, если пользователь User 1 запускает с базовой системы какое-либо приложение, например браузер, реально оно будет запущено с диска D:. При последующей работе приложения любое его обращение с правами пользователя User 1 к базовой системе будет перенаправляться к соответствующей виртуальной системе. При этом приложение, исходно инсталлированное на диск С:, будет работать корректно, поскольку все перенаправления его запросов доступа «прозрачны» для приложения, в частности, корректно будут сохраняться временные данные, cookies, настройки, кэшированная информация и т.д.
Хост платформа
Базовая система
/
Виртуальная система
Виртуальная система
ПО, выполняющее перенаправление Администрирование запр°с°в
Рис. 1. Схема виртуализации системы: ПО - программное обеспечение средства защиты
Отметим, что если пользователь User 2 запускает с базовой системы какое-либо приложение, например, тот же браузер, реально оно будет запущено уже с диска E:. При этом это приложение, инсталлированное на диск С:, будет работать корректно, поскольку все перенаправления его запросов доступа «прозрачны» для приложения, но в этом случае они уже будут сохраняться на диске E:.
Соответствующим образом запретим пользователю доступ User 1 к диску E: (с этим диском работает пользователь User 2), а пользователю User 2 - к диску D:.
Таким образом, получаем полную изолированность сессий по пользователям, в том числе и изолированность системного пользователя; успешная атака, осуществленная на приложение, запущенное каким-либо интерактивным пользователем, не приведет к несанкционированной модификации (или удале -нию элементов) как базовой системы, так и виртуальных систем иных пользователей. Важно, что в результате виртуализации системы мы всегда имеем доверенную операционную систему (базовую систему), с которой осуществляется загрузка и с которой может быть восстановлена виртуальная система, подвергшаяся успешной атаке, поскольку с правами интерактивного пользователя, под которыми запускаются приложения, доступ к ней осуществить невозможно.
Достоинства данной технологии для решения рассматриваемой задачи защиты достаточно очевидны: запускаются только одна операционная система (базовая система) и только одно средство защиты, реализующее перенаправление запросов доступа к файловым объектам (рис. 1), что практически не приводит к дополнительной загрузке вычислительных ресурсов и не усложняет задачу администрирования. Как видим, принципиально меняется и собственно идея виртуализации: запускаются не отдельные виртуальные машины для пользователей, а только одна система, виртуализуется лишь та часть системы (для каждого пользователя, включая системного, - своя), с которой непосредственно должен работать пользователь.
Техническое решение, реализующее используемый для виртуализации системы метод перенаправления запросов доступа к неразделяемым файловым объектам, авторами запатентовано [11], практически реализовано в комплексной системе защиты информации «Панцирь+» для ОС Microsoft Windows (далее будем использовать для иллюстраций интерфейсы, разработанные для этой системы защиты) [12] и апробировано.
Интерфейс задания и отображения заданных правил перенаправления запросов доступа к файловым объектам, реализованных в данной системе защиты, показан на рис. 2.
В качестве объектов доступа, в отношении которых будет применено заданное правило перенаправления запросов доступа, могут выступать файлы, каталоги, логические диски.
Для упрощения задачи администрирования в качестве субъекта доступа в правилах перенаправления используется сущность «профиль» (рис. 2). В один профиль объединяются субъекты, для которых назначаются одинаковые правила перенаправления к файловым объектам.
Отметим, что техническое решение [11] исходно разработано и используется для разделения между субъектами доступа не разделяемых системой и приложениями файловых объектов, например, каталогов, используемых для временного хранения файлов. Без подобного решения невозможно корректно реализовать разграничительную политику доступа, в частности, разделительную, предполагающую полное изолирование сессий - режимов обработки информации различных уровней конфиденциальности.
Рис. 2. Интерфейс задания и отображения заданных правил перенаправления запросов доступа
к файловым объектам
Абстрактная модель системы
Построим абстрактные модели системы и виртуальной системы, на которых рассмотрим различные стратегии атак, и оценим эффективность предлагаемой технологии виртуальных системных средств для решения рассматриваемой задачи защиты.
Пусть на операционной системе OS имеются следующие субъекты (Subjects):
- sp - процесс системы;
- adm - администратор;
- u1 - первый пользователь;
- u2 - второй пользователь.
Это можно записать следующим образом: Subjects = {sp, adm, u1, u2}. Также на OS установлены следующие объекты (Objects):
- S - системные файлы, которые содержат:
- SE - исполняемые файлы операционной системы,
- CF - конфигурационные файлы (различные текстовые и бинарные файлы);
- P - пользовательские приложения;
- UF - пользовательские файлы.
Тогда Objects = Su P и UF, где S = SEи CF; P = {рь..., pN}, гдеpi- установленное приложение i е 1..N, N - количество приложений, установленных в системе; SE = {seb..., seM}, где sei - установленное системное приложение ie1.M; CF = {cf1...,cfK}, где cf - конфигурационный файл, i е1..К; UF = {uJ[,...,ufj}, где uf -пользовательский файл, i е 1..J.
При работе с операционной системой OS пользователь u1 имеет область доступа CONF1 (конфигурация первого пользователя), куда входят:
- P1 - подмножество программ P, доступное для u1;
- CF1 - подмножество конфигурационных файлов CF, доступное для u1;
- UF1 - подмножество UF: файлы, хранящие пользовательские настройки пользователя u1.
Аналогично пользователь u2 имеет область доступа CONF2 (конфигурация второго пользователя), куда входят:
- P2 - подмножество P, доступное для u2;
- CF2 - подмножество CF, доступное для u2;
- UF2 - файлы, хранящие пользовательские настройки пользователя u2.
Это можно записать следующим образом:
CONF1 = P1 u CF1 u UF1; CONF2 = P2 u CF2 u UF2.
Следует отметить, что в общем случае множества P1 n P2 , CF1 n CF2, UF1 n UF2 могут быть непустыми: P1 n P2 Ф 0 (используются те же программы), CF1 n CF2 Ф 0 (для учетных записей не разделяются конфигурационные файлы, например, для приложения), UF1 n UF2 Ф 0 (не разделяются пользовательские настройки, например, для приложения).
Обозначим символом x^A отношение, состоящее в том, что для любого объекта из А субъект x может читать этот объект и, если это исполняемый файл, может его запускать: x^A:VaeA, x может прочесть (исполнить) a, где xeSubjects, A с Objects.
Обозначим символом x^A отношение, состоящее в том, что для любого объекта из A субъект x может читать и изменять этот объект:
x^A: VaeA, x может прочесть (и исполнить) и изменить a, где x e Subjects, A с Objects.
Из приведенных обозначений следует, что если x^A, то x^A, обратное неверно. Тогда можно записать правила доступа всех субъектов следующим образом:
sp^Objects
adm^Objects
щ ^ CONF1 и щ ^ SE u (P \ P1)
u2 ^ CONF2 и u2 ^ SE u (P \ P2)
Каждому пользователю доступна для записи своя конфигурация, а для чтения и запуска - системные и пользовательские приложения, установленные на систему.
Рассмотрим различные сценарии атак.
Сценарий 1. Пользователь является злоумышленником.
Пользователь u_ может модифицировать CONF_, которая состоит из P_, UF_, CF_. Так как P_ n P2 Ф 0, CF_ n CF2 Ф 0, UF_ n UF2 Ф 0, т.е. могут существовать программы, конфигурационные файлы и пользовательские файлы, общие для нескольких пользователей, то пользователь u1 может изменить настройки пользователя u2.
Сценарий 2. Происходит заражение системного исполняемого файла операционной системы.
Пусть заражен некоторый системный исполняемый файл se_eSE. Так как u1^SE и u2^SE, то u1^se1 и u2^se1. В результате оба пользователя оказываются под воздействием заражения и используют зараженный файл se1.
Сценарий 3. Происходит заражение пользовательского исполняемого файла.
Пусть заражен некоторый пользовательский исполняемый файл p_ eP. Если только один пользователь имеет доступ к этому файлу, т.е. p_ eP1\P2 или p_ eP2\P_, тогда только один из пользователей u_ или u2 соответственно оказываются под влиянием зараженного файла. Если же исполняемый файл доступен обоим пользователям, т.е. p_eP_nP2, то оба пользователя оказываются под воздействием зараженного файла.
Сценарий 4. Кража информации из конфигурационных файлов.
Пусть пользователь u_ запускает исполняемый файл e1eSEuP1, который является зараженным. Тогда приложение e_ выполняется с правами пользователя u_ и имеет доступ к следующим файлам: e_ ^ CONF_ (где CONF_ = P_ u CF_ u UF_) и e_ ^ SE u (P \ P_). Так как P_ n P2 , CF_ n CF2, UF_ n UF2 могут быть непустыми, может произойти кража данных не только одного пользователя, но и другого пользователя, не запускавшего зараженный файл.
Сценарий 5. Оказывается заражен исполняемый файл, выполняемый системным процессом sp или администратором.
Пусть файл f e SE является зараженным, далее он запускается системным процессом или администратором. Так как и администратор, и системный процесс имеют полный доступ к системе (sp^Objects, adm^Objects), то вся система оказывается доступна для процесса, запущенного из файлаf
Абстрактные модели виртуализации системы
Полная виртуализация системы. При реализации технологии виртуализации системного средства исходная абстрактная модель системы изменяется следующим образом.
Субъекты системы остаются теми же: Subject = {sp, adm, u_, u2}. Однако, так как виртуализация системы предполагает создание копий, на которые перенаправляются запросы пользователя, то множество объектов операционной системы меняется. А именно, для каждого пользователя создается своя копия системы: Objectsan = Objects u Objects_ u Objects2 - множество всех объектов, установленных на операционной системе. При этом Objects = S u P u UF - множество объектов, изначально установленных на систему. В случае полного копирования файлов операционной системы копии этих файлы попадают во все множества файлов, доступные для каждого из пользователей u1 и u2. В случае частичного копирования только некоторое подмножество этих файлов попадает во множества доступных файлов для пользователей u_ и u2. Здесь подмножества определяются таким же образом, как и без использования виртуальных систем, т.е. S = SE u CF, а P = {p_,..., pN}, где pi - установленное приложение i e 1..N, N - количество приложений, установленных в системе. SE = {se_,..., seM}, где sei - установленное системное приложение ie 1..M, CF = {cf_,...,cfK}, cf - конфигурационный файл, i e 1..K, UF = {uf_,...,ufj}, uf - пользовательский файл, i e 1..J.
Рассмотрим случай полного копирования файлов операционной системы (полная виртуализация системы) и опишем множество объектов, доступных для пользователей u1 и u2.
Обозначим и отношение, состоящее в том, что один объект является копией другого. Пусть объект o1 был создан операцией копирования объекта o2, тогда o1 и o2.
Objects1 = S1 u P1 u UF1, где S1 и S, P1 и P, UF1 и UF.
Objects2 = S2 u P2 u UF2, где S2 и S, P2 и P, UF2 и UF.
Здесь St = SEt и CFt, t e{1,2} - индекс пользователя (для щ. t = 1, для u2. t = 2), а Pt = {pt1,..., pN}, где pti - установленное приложение i e1..N, N - количество приложений, установленных в виртуальной системе для пользователя t. SEt = {set1,..., seM}, где seti - установленное системное приложение ie1..M, CFt = {cffl,...,cfK}, где cfti - конфигурационный файл, i e1..K, (7Ft = {ufb...,uf/}, ufti - пользовательский файл, i e 1..J.
Следующим этапом организации работы в виртуальной системе являются правила перенаправления (которые также будем обозначать и). Пусть выполняются перенаправления всех операций чтения и (или) записи файлов из множества O1 на их копию O2 | O2 и O1 для пользователя u.
L,u
Oí 02,
где L = {г}, или L = {w}, или L = {r,w} - множество типов операций, r - операция чтения, w - операция записи. Тогда можно записать все правила перенаправления для исходной системы в виртуальные системы в следующем виде.
{r,w},u1
Objects-> Objects t,
{r,w},u2
Objects-> Objects2.
Для каждого из пользователей ub u2 выделяется своя копия системы, и все запросы пользователя на чтение и запись перенаправляются на нее.
Учитывая, что перенаправление выполняется до проверки прав доступа к объекту, для пользователей u1 и u2 можно назначить следующие права.
щ ^ Objects'], u2 ^ Objects2.
Рассмотрим сценарии атак применительно к виртуальным системам с полной виртуализацией. Сценарий 1. Пользователь u ^ является злоумышленником.
Пользователь u1 может модифицировать множество файлов Objects1, которое является копией множества Objects. Однако конфигурация пользователя u2 остается недоступной для пользователя ub так как Objects^ n Objects2 = 0. В сравнении с обычным использованием системы применение виртуальных систем позволяет обезопасить пользователей системы от злоумышленной модификации одним из пользователей чужих конфигураций.
Сценарий 2. Происходит заражение системного исполняемого файла операционной системы. Пусть заражен некоторый системный исполняемый файл se je SE, SE с Objects. Так как ux^Objectsx, u2^Objects2 и ни один из пользователей не имеет доступа к Objects, то для каждого из пользователей u1 и u2 имеется своя копия файла se1, а именно. se11 и se1 и se12 и se1, где seneSEb se12eSE2, SE1 с Objects1, SE2 с Objects2. Правила перенаправления настроены таким образом, что при обращении обоих пользователей к любому файлу из Objects доступ фактически осуществляется к файлу из копии, специально созданной для каждого из них. Поэтому каждый пользователь обращается к файлам se11 и se12, которые не были заражены. Каждый из пользователей имеет доступ только к своей копии файла se1. u1—^se11 и u2—se12 .
{r,w},u1
sei-> sen,
{r,w},u2 sei ^ se^2.
В результате ни один из пользователей не оказывается под воздействием заражения, так как они используют копии файла se1. В сравнении с использованием оригинальной системы пользователи оказываются защищенными от данного типа угроз.
Сценарий 3. Происходит заражение пользовательского исполняемого файла.
Пусть заражен некоторый пользовательский исполняемый файл p1e P. Так как P с Objects, то ни один из пользователей u1, u2 не имеет доступа к файлу p1. Ввиду включенного перенаправления каждый из них использует свою копию этого файла p11 и p1, p12 и p1.
{r,w},u1
Pl->PÍÍ,
{r,w},U2
P2 ->Pl2.
Следовательно, ни один из пользователей не оказывается под влиянием заражения. По сравнению с использованием оригинальной системы отсутствует вероятность того, что зараженный файл используют один или более пользователей системы.
Рассмотрим другой вариант этого сценария, при котором зараженный файл находится в одной из копий системы. Пусть заражен пользовательский исполняемый файл p11 из копии Objects1 одного из пользователей u1. p11 e P1, P1 с Objects1, p11 и p1, где p1 e P, P с Objects. Единственный пользователь, который имеет доступ к этому файлу - это u1. u1—p11. Так как пользователь u2 не имеет доступа к файлу p11 и имеет свою копию этого файла p12, p12 и p1, то он работает только со своей копией файла и не оказывается под
влиянием заражения. Таким образом, виртуальные системы локализуют заражение и предотвращают распространение заражения на других пользователей системы.
Сценарий 4. Кража информации из конфигурационных файлов
Пусть пользователь щ запускает исполняемый файл, который является зараженным, e11eSE1uP1, SE1 с Objects1, P1cObjects1. Тогда приложение en выполняется с правами пользователя щ и имеет доступ к файлам e11 ^ Objects1. Таким образом, под воздействием оказываются только файлы пользователя u1, файлы остальных пользователей, например пользователя u2, недоступны, так как хранятся в Objects2, к которому у пользователя u1 нет доступа. Таким образом, виртуальные системы устраняют вероятность кражи информации о чужой конфигурации.
Сценарий 5. Оказывается заражен исполняемый файл, выполняемый системным процессом sp или администратором.
Пусть файл f е SE является зараженным. Он запускается системным процессом или администратором. Так как и администратор, и системный процесс имеют полный доступ к системе (sp^Objectsan, adm^Objectsall), то вся система оказывается доступной для процесса, запущенного из файла f Однако процессу f необходимо определить, что применяются виртуальные системы и что необходимо заразить файлы копии. Это не обеспечивает надежную защиту, но, тем не менее, создает возможность сохранить файлы копий нетронутыми.
Частичная виртуализация системы. Частичная виртуализация предполагает создание копий с последующим перенаправлением к ним запросов доступа субъектов не всего системного средства, а некоторой его части. При реализации частичной виртуализации абстрактная модель виртуальной системы изменяется следующим образом.
Субъекты системы остаются теми же: Subjects = {sp, adm, u1, u2}. Однако, так как виртуализация системы предполагает создание копий части системы, на которые перенаправляются запросы пользователей, то множество объектов операционной системы меняется. Для каждого пользователя создается своя копия части системы: Objectsall = Objects u Copy1 u Copy2 - множество всех объектов, установленных на операционной системе.
Множество объектов, изначально установленных на систему, определяется аналогично предыдущим случаям: Objects = S u P u UF. Так как выполняется частичное копирование, то только часть файлов попадает в копию для каждого из пользователей u1 и u2. Какие файлы переносить в копию, а какие - нет, определяется необходимым уровнем изоляции конфигураций пользователей.
Copy1 и Copy2 состоят из файлов, скопированных из множества Objects. Обозначим подмножества файлов, которые были скопированы из множества Objects, как Copyi1 и Copyl2, Copyi1 с Objects, Copyl2 с Objects, тогда Copy1 и Copyi1 и Copy2 и Copyi2. Если же копии Copyi1 и Copyi2 совпадают с множеством Objects объектов, изначально установленных на систему, то это - случай полного копирования.
Опишем подмножества файлов из изначальной системы, которые копируются для пользователей u1 и u2 соответственно, следующим образом:
- Copyi1 = Si1 u Pi1 u UFi1; каждое из множеств Si1, Pi1, UFi1 может быть пустым;
- Copyi2 = Si2 u Pl2 u UFi2; каждое из множеств Sl2, Pi2, UFi2 также может быть пустым.
Отметим, что копируемые файлы могут как быть совершенно различными, так и совпадать для разных пользователей, т.е. Copyi1 n Copyi2 з 0. Тогда частичные копии для пользователей u1 и u2 можно описать так:
Copy1 = Sc1 u Pc1 u UFc1, где Srf и Sfl, Prf и Pn, UF^ и UFл,
Copy2 = Sc2 u Pc2 u UFc2, где Sc2 и Sl2, Pc2 и Pi2, UFл и UFa.
Также для использования виртуальных систем следует назначить правила перенаправления. Перенаправление осуществляется таким образом, что все операции пользователя к подмножеству скопированных файлов оригинальной системы фактически адресуются к копии, созданной для этого пользователя. Правила перенаправления для этого случая запишем следующим образом:
{r,w},u1
Copyil-> Copyt,
{r,w},U2
Copyi2-> Copy2.
Учитывая, что перенаправление выполняется до проверки прав доступа к объекту, для пользователей u1 и u2 назначаются следующие права:
щ ^ Copy1 u CF1 \ CF,! u P1 \ Pfl u UF1 \ UF,! и u1 ^ SE \ SEa u (P \ Pfl) \ P1,
u2 ^ Copy2 u CF2 \ CF,2 u P2 \ Pa u UF2 \ UFi2 и u2 ^ SE \ SEi2 u (P \ Pi2) \ P2.
Оригинальные права пользователя сохраняются с тем лишь отличием, что доступ к скопированным файлам осуществляется к копии, и оригинальные файлы становятся недоступными для пользователя. Тем не менее, пользователю добавляются права на полный доступ к специально созданной для него частичной копии.
Рассмотрим сценарии атак применительно к виртуальным системам с частичной виртуализацией.
Сценарий 1. Пользователь u ^ является злоумышленником.
Пользователь u1 может модифицировать множество файлов Copy1, которое является копией множества Objects. Вся конфигурация пользователя u2, скопированная для виртуальной системы, остается недоступной для пользователя u1, так как Copy1 n Copy2 = 0, даже если были скопированы одинаковые файлы. Тем не менее, если файлы, которые не были скопированы пользователем u1, совпадают с файлами, которые не участвуют в виртуальной системе пользователя u2, т.е. (CF1 \ CF^) n (CF2 \ CFi2) Ф 0, или (P1 \ Pi1) n (P2 \ Pl2) Ф 0, или (UF1 \ UFi1) n (UF2 \ UFi2) Ф 0, то пользователь u1 сможет модифицировать файлы из пересечения. Таким образом, частичная копия позволяет устранить пересекающиеся части конфигураций пользователей, а остальная часть системы остается не защищенной от такой угрозы.
Сценарий 2. Происходит заражение системного исполняемого файла операционной системы.
Пусть заражен некоторый системный исполняемый файл se1e SE, SE с Objects. Если se1 e Objects \ Copyü или se1 e Objects \ Copyi2, т.е. этот файл не содержится во множестве файлов, скопированных одним или двумя пользователями, то один или оба пользователя используют зараженный файл. Если файл se1 был скопирован для виртуальной системы пользователя, этот пользователь использует оригинальную, не подвергшуюся заражению копию этого файла. Таким образом, если пользователи используют виртуальные системы с частичной копией и оригинальная версия была сохранена в эту копию, то заражение исходного файла никак не влияет на работу пользователей. Однако, если файл не был скопирован, то пользователи будут использовать зараженный файл.
Сценарий 3. Происходит заражение пользовательского исполняемого файла.
Пусть заражен некоторый пользовательский исполняемый файл p1 e P. Рассмотрим данный сценарий для пользователя u1. Для пользователя u2 можно записать аналогичные утверждения с изменением рассматриваемых множеств доступных файлов и заменой индексов в выражениях. Аналогично предыдущему сценарию, необходимо определить, принадлежит ли файл p1 множеству скопированных файлов пользователя из оригинальной системы Pi1. Если p1 e Pi1, то существует файл pc1 такой, что pc1 принадлежит частичной копии пользователя u1 - Copyc1 и, в частности, множеству пользовательских приложений Pc1, и выполняется pc1 и p1. Ввиду включенного перенаправления пользователь u1 использует файл pc1 при обращении к p1.
{r,w},u1
Pi -> Pel-
Следовательно, пользователь не оказывается под влиянием заражения.
Если же p1 í Pc1, то пользователь u1 использует зараженный файл, так как перенаправление в виртуальную систему не выполняется для этого файла. Таким образом, пользователь не подвержен риску, если зараженные файлы были ранее скопированы в виртуальную копию.
В другом варианте этого сценария зараженный файл находится в одной из частичных копий системы. Пусть заражен пользовательский исполняемый файл pe1 из копии Copy1 одного из пользователей u1. pc1 e Pc1, Pc1 с Copy1, pc1 и p1, где p1 e P, P с Objects. Единственный пользователь, который имеет доступ к этому файлу - это u1. u1— pc1. Так как пользователь u2 не имеет доступа к файлу pc1 и использует либо оригинальный файл p1, либо свою копию p12, p12 и p1, то он не имеет доступа к зараженному файлу pc1. Таким образом, виртуальные системы локализуют заражение при частичном копировании и предотвращают распространение заражения на других пользователей системы.
Сценарий 4. Кража информации из конфигурационных файлов.
Пусть пользователь u1 запускает исполняемый файл, который является зараженным. Возможны два случая, когда feSE1 и P1, SE1 с Copy1, P1 с Copy1, т.е. f запускается из копии системы, либо когда feSE и P, SE с Objects, P с Objects. В любом из этих случаев приложение f выполняется с правами пользователя u1 и имеет доступ к следующим файлам. f ^ Copy1 и CF1 \ CFÜ и P1 \ P й и UF1 \ UF й и u1 — SE \ SE,! и (P \ P,1)\ P1. В результате под воздействием оказываются не только файлы пользователя u1, но и, возможно, файлы остальных пользователей, например пользователя u2, если конфигурации этих пользователей пересекаются и не были скопированы для обоих из них. Остальные же данные пользователя u2, которые хранятся в Copy2, недоступны для кражи, так как пользователь u1 не имеет к ним доступа. Таким образом, виртуальные системы с частичным копированием снижают количество данных, которые могут быть доступны остальным пользователям для кражи.
Сценарий 5. Оказывается заражен исполняемый файл, выполняемый системным процессом sp или администратором.
Пусть файл f e SE является зараженным. Он запускается системным процессом или администратором. Так как и администратор, и системный процесс имеют полный доступ к системе (sp^Objectsan, adm^Objectsan), то вся система оказывается доступной для процесса, запущенного из файла f. Однако процессу f необходимо определить, что применяются виртуальные системы. Кроме того, так как копирование выполнено частично, то процессу f нужно определить, где расположены копии, и что их тоже необходимо заразить. Это, также как и в случае полного копирования, не является надежным методом защиты, но, тем не менее, создает возможность сохранить файлы копий нетронутыми.
Исследование построенных абстрактных моделей виртуализации системы позволяет сделать
следующие выводы.
1. При реализации полной виртуализации системы достигается и полное изолирование системных и конфигурационных файлов системы и приложений. Доступ к конфигурационным файлам любого пользователя возможен только для этих пользователей, при этом все заражения локализуются его виртуальной системой.
2. Применение частичной виртуализации позволяет найти компромисс между объемом создаваемых копий виртуализируемой системы и защищенностью пользовательской конфигурации. Как было показано при рассмотрении сценариев атак, при частичном копировании большую роль играют следующие обстоятельства: имеется ли копия оригинального файла, который был заражен; какие из файлов были созданы копированием. Чем полнее копия, тем ниже шанс, что пользователь будет использовать зараженный не по его вине файл и что его конфигурация будет изменена или считана другим пользователем. В качестве рекомендации можно предложить переносить в виртуальную систему все системные объекты и ключевые пользовательские приложения, а также конфигурационные файлы, которые находятся в общем доступе для нескольких пользователей.
Заключение
В работе при изложении и проведении исследований эффективности технологии виртуализации системных средств в качестве субъекта доступа рассматривался пользователь (учетная запись). Однако при реализации разграничительной политики доступа субъектов к объектам в современной информационной системе субъект доступа уже должен задаваться сущностью «пользователь, процесс» - какой пользователь и каким процессом запрашивает доступ к объекту. Для реализации подобной схемы контроля и разграничения прав доступа может использоваться запатентованное техническое решение [13]. Именно процесс в современной информационной системе с той или иной вероятностью (различающейся на порядки для различных процессов) несет в себе угрозу атаки как по причине потенциальной возможности выявления уязвимости [14], так и по причине возможности наделения процесса вредоносными свойствами [15]. Поэтому различным процессам в общем случае должны назначаться различные права доступа к объектам (в противном случае они одинаковы и наследуют права доступа к объектам запустившего их пользователя).
С учетом сказанного задачу виртуализации системы (полную или частичную) можно рассмотреть применительно к процессу как к субъекту доступа. Виртуализация системы может реализовы-ваться для критичных процессов (запускаемых одним пользователем), для которых по тем или иным причинам высока вероятность реализации успешной атаки. Однако эти вопросы выходят за рамки настоящей работы и являются предметом дальнейших исследований авторов.
Литература
1. Щеглов К.А., Щеглов А.Ю. Метод сессионного контроля доступа к файловым объектам. Вопросы практической реализации // Вестник компьютерных и информационных технологий. 2014. № 8 (122). С. 54-60.
2. Щеглов К.А., Щеглов А.Ю. Новый подход к защите данных в информационной системе // Изв. вузов. Приборостроение. 2015. Т. 58. № 3. С. 157-166. doi: 10.17586/0021-3454-2015-58-3-157-166
3. Щеглов К.А., Щеглов А.Ю. Защита от атак на уязвимости приложений // Информационные технологии. 2014. № 9. С. 34-39.
4. Щеглов А.Ю., Щеглов К.А. Система контроля доступа к файлам на основе их автоматической разметки. Патент РФ № 2524566. Бюл. 2014. № 21.
5. Щеглов К.А., Щеглов А.Ю. Контроль доступа к статичным файловым объектам // Вопросы защиты информации. 2012. № 2 (97). С. 12-20.
6. Kim S.-K., Ma S.-Y., Moon J. A novel secure architecture of the virtualized server system // Journal of Supercomputing. 2015. doi: 10.1007/s11227-015-1401-4
7. Jithin R., Chandran P. Virtual Machine Isolation // Communications in Computer and Information Science.
2014. V. 420 CCIS. P. 91-102. doi: 10.1007/978-3-642-54525-2_8
8. Pektas A., Acarman T. A dynamic malware analyzer against virtual machine aware malicious software // Security and Communication Networks. 2014. V. 7. N 12. P. 2245-2257. doi: 10.1002/sec.931
9. Luo X., Yang L., Hao D., Liu F., Wang D. On data and virtualization security risks and solutions of cloud computing // Journal of Networks. 2014. V. 9. N 3. P. 571-581. doi: 10.4304/jnw.9.3.571-581
10. Win T.Y., Tianfield H., Mair Q. Virtualization security combining mandatory access control and virtual machine introspection // Proc. IEEE/ACM 7th Int. Conf. on Utility and Cloud Computing, UCC 2014. London,
2015. P. 1004-1009. doi: 10.1109/UCC.2014.165
11. Щеглов А.Ю., Щеглов К. А. Система переформирования объекта в запросе доступа. Патент РФ № 2538918. Бюл. 2015. № 1.
12. Щеглов А.Ю., Павличенко И.П., Корнетов С.В., Щеглов К.А. Комплексная система защиты информации «Панцирь+» для ОС Microsoft Windows. Свидетельство о государственной регистрации программы для ЭВМ №2014660889.
13. Щеглов А.Ю., Щеглов К. А. Система контроля доступа к ресурсам компьютерной системы с субъектом доступа «пользователь, процесс». Патент РФ № 2534599. Бюл. 2014. № 33.
14. Щеглов К. А., Щеглов А.Ю. Защита от атак на уязвимости приложений. Модели контроля доступа // Вопросы защиты информации. 2013. № 2 (101). С. 36-43.
15. Щеглов К.А., Щеглов А.Ю. Защита от атак со стороны приложений, наделяемых вредоносными функциями. Модели контроля доступа // Вопросы защиты информации. 2012. № 4 (99). С. 31-36.
Ковешников Михаил Геннадьевич - студент, Университет ИТМО, Санкт-Петербург, 197101, Российская
Федерация, Mike_35_92@mail.ru
Щеглов Константин Андреевич - менеджер по развитию, ООО «НПП «Информационные технологии
в бизнесе», Санкт-Петербург, 194044, Российская Федерация, scheglov.konstantin@gmail.com
доктор технических наук, профессор, генеральный директор, ООО «НПП «Информационные технологии в бизнесе», Санкт-Петербург, 194044, Российская Федерация, info@npp-itb.spb.ru
student, ITMO University, Saint Petersburg, 197101, Russian Federation, Mike_35_92@mail.ru
development manager, OOO «Scientific Production Enterprise «Information technologies in business», Saint Petersburg, 194044, Russian Federation, scheglov.konstantin@gmail.com D.Sc., Professor, General Director, OOO «Scientific Production Enterprise «Information technologies in business», Saint Petersburg, 194044, Russian Federation info@npp-itb.spb.ru
Щеглов Андрей Юрьевич
Michael G. Koveshnikov Konstantin A. Shcheglov
Andrey Yu. Shcheglov
