Модель Грэхэма-Деннинга

Концепцию дискреционного разграничения доступа впервые предложил Батлер В. Лэмпсон^[1]. Развивая эту теорию, Скотт Грэхэм и Питер Деннинг формализовали введённые Лэмпсоном принципы и построили одну из первых фундаментальных моделей разграничения доступа^[2]. В основу модели легло понятие о том, что каждый процесс имеет уникальный идентификационный номер, который системой прикрепляется к каждой попытке доступа процесса к объекту системы. Модель Грэхэма — Деннинга сформировала основу для последующих систем безопасности, например, модели Харрисона — Руссо — Уллмана (HRU).

В модели определяются следующие компоненты^[3]:

• Множество объектов (O) — сущностей, доступ к которым должен контролироваться. В контексте операционных систем объектами могут выступать страницы памяти, программы, устройства внешней памяти компьютера, инструкции и файлы.
• Набор субъектов (S), чей доступ к объектам должен контролироваться. Обычно субъектом считается пара (процесс, домен), где процесс — это активная выполняющаяся программа, а домен — окружение её выполнения. Например, в IBM System/370 доменами являются состояния процессора, супервизора или прикладной программы. Поскольку субъекты также требуют защиты, они рассматриваются как объекты.

Для каждого объекта определяется субъект-владелец, а для каждого субъекта — субъект-контролёр. Они имеют особые права по отношению к соответствующему объекту или субъекту^[4].

• С каждым типом объекта связан специальный управляющий процесс — монитор обращений, через который проходят все попытки доступа к объектам. Примерами мониторов могут быть системные файлы, оборудование для выполнения инструкций или средства адресации памяти.
• Набор правил доступа (R), определяющих возможные типы доступа субъектов к объектам. В модели Грэхэма — Деннинга задаются восемь правил доступа, определяющих действия и операции, доступные субъекту по отношению к объекту^[4]:
  • «Создание объекта», «создание субъекта», «удаление объекта» и «удаление субъекта» позволяют субъекту создавать или удалять объекты/субъекты в системе.
  • «Чтение прав доступа» позволяет субъекту получать сведения о текущих правах субъекта к объекту.
  • «Назначение прав доступа» позволяет владельцу объекта назначать любое право другому субъекту к объекту.
  • «Удаление прав доступа» позволяет субъекту удалить право другого субъекта к объекту (удаление доступно владельцу объекта или контролёру субъекта, права которого удаляются).
  • «Передача прав доступа» позволяет субъекту передать одно из своих прав к объекту другому субъекту; различают передаваемые и непередаваемые права: обладатель передаваемого права может передавать его дальше, непередаваемого — нет.
• Правила реализуются с помощью матрицы контроля доступа A, строки которой соответствуют субъектам, столбцы — объектам (включая субъекты), а элементы — атрибуты доступа A[S,O] содержат перечень разрешённых привилегий субъекта s к объекту o.

В следующей таблице приведены операции над матрицей доступа и соответствующие предусловия и результаты^[5]. Субъект, выполняющий команду, обозначен x. r* — право доступа, которое может быть впоследствии передано другому субъекту; r (без «*») — непередаваемое право.

Модель безопасности должна решать следующие задачи^[6]:

1. отображать состояние безопасности,
2. обеспечивать доступ субъектов к объектам только в предусмотренных состоянием безопасности случаях и видах,
3. позволять субъектам в определённой степени изменять состояние безопасности.

Первая задача решается посредством наглядного представления состояния системы матрицей доступа A.

Выполнение третьей задачи основано на правилах редактирования матрицы доступа. Изменения состояния безопасности (матрицы доступа) допускаются лишь такими правилами, которые контролируются и исполняются мониторами матрицы доступа. Единственно авторизованный субъект имеет право изменять (в том числе добавлять или удалять) атрибуты доступа; для идентификации такой авторизации используются рассмотренные выше понятия владельца и контролёра объекта/субъекта, а также механизм передаваемых прав.

Вторая задача реализуется предположением, что каждую попытку доступа субъекта к объекту перехватывает и проверяет монитор обращений. Алгоритм проверки доступа следующий^[2]:

1. субъект s инициирует доступ а к объекту o;
2. система передаёт запрос (s, а, o) монитору O;
3. монитор O проверяет в матрице доступа наличие а в A[s, o]. При наличии права доступ разрешён; если нет — запрещён, принимаются меры по устранению нарушения.

Мониторы объектов интерпретируют атрибуты доступа во время попытки обращения субъекта. Поскольку идентификатор вызывающего субъекта закрепляется системой и предоставляется монитору, субъект не может обмануть монитор, предъявив неверную сущность для проверки в A^[3]. Так как никаким субъектам не предоставляется доступ к самой матрице A, это является основой для доказательства корректности.

Чтобы доказать корректность модели безопасности, необходимо показать, что субъект может получить доступ к объекту только при наличии авторизации^[2].

• Любое действие субъекта, не изменяющее состояние безопасности, должно быть авторизовано.
• Любое действие, меняющее состояние безопасности, не должно приводить к несанкционированному доступу субъектов к объектам.

Корректность первого положения обеспечивается тем, что к каждой операции системой прикрепляется неотчуждаемый идентификатор вызывающего субъекта; корректно реализованный монитор обращений обеспечивает, что неавторизованный субъект не может получить доступ к объекту. Если (а) система корректно прикрепляет идентификатор, (б) монитор делает корректный запрос в матрицу доступа, (в) содержание матрицы может менять только монитор матрицы доступа, то первое требование соблюдается.

По второму положению, предполагая корректную работу монитора матрицы доступа, каждое изменение создаёт новое состояние безопасности определённым, предсказуемым образом. Однако, у некоторых правил разные аспекты доверия: если владелец объекта неосторожен, то недоверенные субъекты могут договориться (или действовать согласованно), чтобы предоставить собой или другим субъектам несанкционированный доступ. Так как модель не решает проблему доверия, необходимо внешнее регулирование либо правовые средства^[4].

Рассмотрим передачу/создание прав доступа: субъект s1 создаёт объект x и раздаёт разные права на него субъектам s2 … sn. Если s1 ни при каких обстоятельствах не хочет, чтобы субъект s0 имел к x доступ, он не должен выдавать s0 вообще никаких прав, а также обязан раздавать всем s2 … sn только непередаваемые права (чтобы никто из них не смог передать право s0). Таким образом, между s1 и получателями доступа к x должно быть чёткое понимание и доверие относительно невозможности передачи права s0; при выполнении доверительных соглашений s1 может раздавать и передаваемые права. Тогда правила создания/передачи прав доступа корректны.

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

Следовательно, описанная система защиты корректна при условии доверительных отношений между субъектами^[2]. Для включения в систему недоверенных субъектов только технических механизмов недостаточно: необходим внешний надзор совместно с системами обнаружения и фиксации нарушений.

Модель Грэхэма — Деннинга может использоваться для обеспечения безопасности как операционных систем, так и баз данных^[7].

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