Введение

Реестр Windows – это иерархическая централизованная база данных, используемая для хранения сведений, необходимых для настройки операционной системы для работы с пользователями, программными продуктами и устройствами.

В реестре хранятся данные, которые необходимы для правильного функционирования Windows. К ним относятся профили всех пользователей, сведения об установленном программном обеспечении и типах документов, которые могут быть созданы каждой программой, информация о свойствах папок и значках приложений, а также установленном оборудовании и используемых портах [1].

Стабильность системного реестра и целостность его содержимого являются жизненно важными для функционирования ОС Windows.

Именно поэтому является актуальной задача исследования вопросов контроля доступа к системному реестру ОС Windows.

Модели контроля доступа

На сегодняшний день разработано три общих модели контроля доступа:

• Принудительный контроль доступа (англ. Mandatory access control, MAC);
• Дискреционный контроль доступа (англ. Discretionary access control, DAC);
• Управление доступом на основе ролей (англ. Role-base access control, RBAC).

Принудительный контроль доступа (англ. Mandatory access control, MAC)

Данная модель изначально разрабатывалась для нужд армии и разведки США [2]. Основное предназначение – обеспечить защиту секретной информации от прочтения пользователями с недостаточным уровнем привилегий.

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

Формально, любая система контроля доступа, которая обладает этим свойством, может считаться системой принудительного контроля доступа, однако де-факто, говоря о принудительном контроле доступа, подразумевается система, которая реализует модель многоуровневой безопасности (Multi-Level Security, MLS).

Согласно модели многоуровневой безопасности, заранее определяется упорядоченный набор уровней секретности (например,  возможны следующие уровни: «совершенно секретно», «секретно», «для внутреннего пользования», «не секретно»). Из этого набора каждому информационному объекту присваивается классификационная метка,  а субъектам системы – уровни доступа.

Общая идея заключается в том, что доступ к объекту заданного уровня секретности могут иметь только субъекты с не меньшим уровнем доступа. Однако, даже в рамках единой модели многоуровневой безопасности, детали алгоритма определения возможности доступа могут отличаться в зависимости от целей системы. И здесь возможны два почти диаметрально противоположных подхода – это модель Белла-Ла Падулы и модель Бибы.

Модель Белла-Ла Падулы (David E. Bell, Leonard J. La Padula, 1973 [3,4]) призвана обеспечить конфиденциальность данных. Модель описывает проблему контроля доступа в терминах переходов между состояниями системы. Каждое состояние описывается совокупностью имеющихся обращений субъектов к объектам. Модель формулирует правила, следование которым гарантирует, что из любого безопасного состояния система может перейти только в другое безопасное состояние.

Суть политики безопасности, определяемой моделью, сводится к двум простым правилам:

• Правило простого свойства безопасности – субъект может читать только те объекты, чей уровень секретности меньше или равен уровню доступа субъекта. Это правило гарантирует что пользователи с недостаточными полномочиями не получат доступ к конфиденциальной информации. Это свойство также иногда формулируется как «запрет чтения вверх».
• Правило *-свойства («звездочка»-свойства) – субъект может писать (дописывать) информацию только в те объекты, чей уровень секретности больше или равен уровню доступа субъекта. Это правило гарантирует, что не произойдет утечка конфиденциальной информации на нижние уровни секретности. Это свойство также иногда формулируется как «запрет записи вниз».

Эти два правила полностью гарантируют конфиденциальность в системе многоуровневой безопасности, однако в некоторых случаях приведенное правило «звездочка»-свойства оказывается неприменимым. Причина этого заключается в том, что позволяя запись (дозапись) в объекты большего уровня секретности, это правило может привести к нарушению целостности данных. В этом случае применяется строгая форма «звездочка»-свойства – запись запрещается как вниз, так и вверх; субъектам разрешено писать только в объекты равного уровня секретности.

В отличии от модели Белла-Ла Падулы, модель Бибы (Kenneth J. Biba), также известная как «модель целостности Бибы» (Biba Integrity Model), призвана обеспечить целостность важных данных [5].

В рамках модели Бибы все объекты и субъекты также классифицируются по заранее определенному упорядоченному набору уровней, однако в модели Бибы уровни имеют другое семантическое значение – здесь это уровни «целостности» или «достоверности».

В соответствии с преследуемой целью и семантикой уровней безопасности модель Бибы устанавливает правила, которые являются диаметрально противоположным тем, что устанавливаются моделью Белла-Ла Падулы:

• Правило простого свойства целостности – субъект может читать только те объекты, чей уровень достоверности больше или равен уровню доступа субъекта. Таким образом, гарантируется, что уполномоченный субъект не будет дезинформирован неполной или недостоверной информацией. Это свойство также иногда формулируется как «запрет чтения вниз».
• Правило *-свойства целостности – субъект может писать только в те объекты, чей уровень достоверности меньше или равен уровню доступа субъекта. Это гарантирует, что субъект не нарушит целостность информации более высоких уровней. Это свойство также иногда формулируется как «запрет записи вверх».

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

Дискреционный контроль доступа (англ. Discretionary access control, DAC)

Как было сказано выше, в системах MAC-модели пользователи не имеют возможности самостоятельно определять права доступа к своим собственным файлам. Это свойство является и главным и преимуществом MAC-модели и ее же главным недостатком. Подобный тоталитарный контроль оказывается эффективным и оправданным для нужд военных ведомств и крупных корпораций, однако оказывается крайне неудобным для среднего и малого бизнеса и домашних пользователей.

Поэтому возникает необходимость в более гибкой модели контроля доступа. Такой моделью является модель дискреционного контроля доступа. Суть дискреционности заключается в том, что любой субъект может по своему усмотрению передать часть своих прав на некоторый объект любому другому субъекту [6].

Возможны несколько подходов к построению дискреционного управления доступом:

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

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

Описание прав доступа должно в явном и недвусмысленном виде задавать для каждой пары субъект-объект все допустимые режимы доступа. Поскольку набор возможных режимов доступа зависит от типа объекта, а количество объектов обычно значительно превосходит количество субъектов, то описание прав доступа закрепляется за объектами.

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

Дальнейшее развитие идея групп пользователей получила в модели управления доступом на основе ролей, которая будет рассмотрена далее.                                                                          

Типичным представителем реализации DAC-модели является механизм ACL (Access Control List) применяющийся в системах Windows семейства NT [7]. В рамках этого механизма, с каждым защищенным объектом ассоциируется дескриптор безопасности (ACL-запись). В дескрипторе безопасности хранится следующая информация:

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

Если список прав доступа не оговаривает определенный случай доступа, то он считается запрещенным по умолчанию.

Право редактирования дескриптора безопасности как отдельное право доступа описывается самим дескриптором. По умолчанию этим правом обладают владелец, системная учетная запись и пользователи из группы «Администраторы».

Параметры наследования дескриптора определяют наследует ли данный объект свой дескриптор от родительского объекта и будет ли дескриптор унаследован дочерними объектами. По умолчанию наследование активно для большинства системных объектов и вновь созданные дочерние объекты (файл в каталоге, подключ в реестре и т.п.) наследуют дескриптор безопасности родительского объекта.

Другим примером реализации DAC-модели является система прав доступа традиционная для UNIX-подобных систем [8,9]. Эта система имеет ряд принципиальных отличий от Windows ACL:

• Все объекты, независимо от типа, имеют одинаковый набор возможных прав доступа – права чтения, записи, исполнения. Но трактовка этих прав различна для разных типов объектов, что вносит некоторую путаницу.
• Система не поддерживает список определений прав доступа для различных субъектов – вместо этого права доступа определяются в терминах трех субъектов – пользователя-владельца, группы-владельца и всех остальных.
• При создании нового объекта, он наследует права доступа не от родительского объекта, а наследует их от процесса, создавшего объект.

По первым двум пунктам система прав доступа UNIX, несомненно, проигрывает Windows ACL по гибкости и широте возможностей; однако на практике нередко оказывается более эффективной именно в силу своей простоты и предсказуемости.

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

Управление доступом на основе ролей (англ. Role-base access control, RBAC)

Данная модель является новейшей и весьма перспективной альтернативой для MAC- и DAC-моделей. До разработки модели управления доступом на основе ролей, MAC и DAC рассматривались как два единственно возможных варианта системы контроля доступа – модель не была MAC-моделью, то она считалась DAC-моделью и наоборот. Однако исследования конца 90-х показали, что модель RBAC не является ни MAC-моделью, ни DAC-моделью [10,11].

Для определения модели RBAC используются следующие соглашения:

• U = Субъект (англ. Subject) = Человек или автоматизированный агент (множество пользователей);
• R = Роль (англ. Role) = Рабочая функция или название, которое определяется на уровне авторизации (множество ролей);
• P = Разрешения (англ. Permissions) = Утверждения режима доступа к ресурсу (множество прав доступа на объекты системы);
• S = Сессия (англ. Session) = Соответствие между U, R и/или P
• UA = Назначение субъекта (англ. Subject Assignment)
• PA: R -> 2^p — функция, определяющая для каждой роли множество прав доступа; при этом для каждого p ∈ P существует r ∈ R такая, что p ∈ PA(r); (англ. Permission Assignment)
• RH = Частично упорядоченная иерархия ролей (англ. Role Hierarchy).
• Один субъект может иметь несколько ролей.
• Одну роль могут иметь несколько субъектов.
• Одна роль может иметь несколько разрешений.
• Одно разрешение может принадлежать нескольким ролям.
• Субъект может иметь множество одновременных сессий с различными разрешениями.

Привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свои роли. Таким образом, управление индивидуальными правами пользователя, по сути, сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем.

При этом назначение пользователем ролей и редактирование разрешений для ролей может производиться только уполномоченными органами (пользователями с административными правами) и не доступно для рядовых пользователей. В этом смысле RBAC-модель также обладает свойством мандатности.

В отличии от DAC-модели, разрешения задаются не на режим доступа к объекту, а на транзакции с объектом. Это позволяет описывать разрешения для сложных операций с составными данными.

Нужно отметить, что в RBAC-модели операции редактирования параметров контроля доступа также являются транзакциями, а значит, могут контролироваться самой системой.

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

Анализ существующего контроля доступа к реестру ОС Windows

Стандартным средством контроля доступа к реестру ОС Windows является механизм ACL реализующий DAC-модель. Объектами, которые находятся под защитой, являются ключи реестра. Отдельные значения в ключе не существуют как самостоятельные объекты и соответственно не могут иметь дескриптор безопасности.

Для каждого ключа определен следующий набор возможных прав доступа:

• Запрос значения
• Задание значения
• Создание подраздела
• Создание символической ссылки (недокументированная возможность).
• Перечисление подразделов
• Подписка на уведомление
• Запись разрешений
• Чтение разрешений
• Смена владельца

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

Ключи, влияние которых распространяется только на отдельного пользователя, открыты для полного доступа со стороны этого пользователя, системы и пользователей из группы «Администраторы», а доступ только для чтения предоставляется пользователям в группе «Ограниченные».

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

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

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

Для защиты системного реестра Windows от атаки по одному из этих сценариев целесообразно внедрить механизм защиты, который бы дополнил имеющийся механизм ACL.

Реализовывать альтернативный механизм на базе DAC-модели, означает фактическое дублирование стандартного механизма защиты. Это временно снизит вероятность успешной атаки, но в конечном итоге не решает указанные проблемы уязвимости.

Таким образом, перспективным является использование MAC-модели либо RBAC-модели.

Поскольку целью защиты системного реестра является сохранение целостности его содержимого, но не обеспечение его конфиденциальности, то в рамках MAC-модели целесообразно использовать модель Бибы.

В рамках RBAC-модели особый интерес представляют описание прав доступа в терминах «умных» транзакций – т.е. контроль не только фактов доступа, но содержимого оперируемых данных.

Выводы

На сегодняшний день разработано три основных модели контроля доступа – MAC-модель, DAC-модель и RBAC-модель. Для контроля доступа к реестру Windows имеются стандартные средства, реализующие DAC-модель. В рамках DAC-модели конфигурация имеющихся средств контроля доступа является оптимальной для системы общего назначения и не требует модификаций. Однако остаются возможные сценарии атаки, которые в рамках DAC-модели полностью исключить невозможно. Для защиты от этих атак целесообразно разработать альтернативный механизм защиты на базе MAC-модели либо RBAC-модели, дополняющий возможности стандартного механизма контроля доступа к реестру ОС Windows.

Список литературы

1. Сведения о реестре Windows для опытных пользователей. // Microsoft® Справка и поддержка.
   http://support.microsoft.com/kb/256986/ru
2. Mandatory access control // Wikipedia, the free encyclopedia. 2009.
   http://en.wikipedia.org/wiki/Mandatory_access_control
3. Bell, David Elliott and La Padula, Leonard J. Secure Computer Systems: Mathematical Foundations. MITRE Corporation. 1973.
   http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf
4. Bell, David Elliott and La Padula, Leonard J. Secure Computer System: Unified Exposition and Multics Interpretation. MITRE Corporation. 1976.
   http://csrc.nist.gov/publications/history/bell76.pdf
5. Biba, K. J. "Integrity Considerations for Secure Computer Systems". MITRE Corporation. 1975.
   http://seclab.cs.ucdavis.edu/projects/history/CD/biba75.pdf
6. Избирательное управление доступом  // Википедия — свободная энциклопедия. 2008.
   http://ru.wikipedia.org/wiki/Избирательное_управление_доступом
7. Access Control Lists // Microsoft Developer Network. 2009
   http://msdn.microsoft.com/en-us/library/aa374872(VS.85).aspx
8. UNIX File Permissions and POSIX ACLs // HP CIFS Server 3.0k Administrator's Guide version A.02.04: HP-UX 11i v1, HP-UX 11i v2, and HP-UX 11i v3.
   http://docs.hp.com/en/B8725-90143/ch03s02.html
9. POSIX Access Control Lists on Linux / Andreas Grünbacher. SuSE Labs. 2003
   http://www.suse.de/~agruen/acl/linux-acls/online/
10. D.F. Ferraiolo and D.R. Kuhn. "Role Based Access Control" 15th National Computer Security Conference, Oct 13-16, 1992, pp. 554-563.
    http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf
11. National Institute of Standards and Technology FAQ on RBAC models and standards. 2007.
    http://csrc.nist.gov/groups/SNS/rbac/faq.html
12. Управление доступом в сложных информационных системах на основе ролевой авторизации / О.С. Бартунов, Е.Б. Родичев, С.Н. Ардатский, С.Н. Назин. 2003.
    http://www.sai.msu.su/~megera/wiki/Rbac-paper
13. Registry Key Security and Access Rights // Microsoft Developer Network. 2005
    http://msdn.microsoft.com/en-us/library/ms724878(VS.85).aspx