Доверенные субъекты

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

Это наблюдение высвечивает еще одну техническую проблему, связанную с правилами БЛМ. Можно сказать, что эти правила обеспечивают средства для предотвращения угрозы нарушения секретности для нормальных пользователей, но не говорят ничего по поводу той же проблемы для так называемых доверенных субъектов. Доверенные субъекты могут функционировать в интересах администратора. Также они могут быть процессами, обеспечивающими критические службы такие, как драйвер устройства или подсистема управления памятью. Такие процессы часто не могут выполнить свою задачу, не нарушая правил БЛМ. Неприменимость БЛМ для доверенных субъектов может быть выражена путем внесения поправки в данное ранее определение операций чтения и записи БЛМ. Но хотя это и делает определение более точным, оно нисколько не облегчает задачу для разработчика, желающего построить безопасный драйвер или утилиту поддержки работы администратора.

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

Проблема системы Z

Джон МакЛин разработал концептуальное описание системы, названной Система Z. Данное описание показывает, что система, удовлетворяющая правилам БЛМ, может иметь ряд проблем с секретностью. Система Z выражается в терминах набора субъектов и объектов, с каждым из которых связан уровень безопасности. Совокупность уровней безопасности для каждого субъекта и объекта в некоторый момент времени описывает состояние системы. Система Z удовлетворяет БЛМ, если во всех состояниях системы комбинации уровней субъектов и объектов таковы, что в этом состоянии никакой субъект не может осуществить запись вниз или чтение сверху.

Предположив, что система Z удовлетворяет условиям БЛМ, можно быть уверенным, что любая угроза секретности будет обнаружена. Однако МакЛин указал на техническую деталь, которая не очевидна в таких системах. Если в некотором состоянии секретный субъект захотел прочитать совершенно секретный объект, то до тех пор, пока система удовлетворяет БЛМ, осуществить это будет невозможно. Но МакЛин заявляет, что ничто в БЛМ не предотвращает систему от "деклассификации" объекта от совершенно секретного до секретного (по желанию совершенно секретного пользователя).

В качестве иллюстрации можно привести следующий пример. Допустим, субъект с высокой степенью доверия A читает информацию из объекта, уровень классификации которого также равен А. Далее данный субъект понижает свою степень доверия до уровня В (А > В). После этого он может записать информацию в файл с классификацией В. Нарушения БЛМ формально не произошло, но безопасность системы нарушена.

Фактически, МакЛин описал конфигурацию, в которой все субъекты могут читать и записывать любой объект путем назначения соответствующих уровней безопасности объекта перед выполнением запросов на доступ. В такой системе, которая очевидно не обеспечивает секретность информации, все состояния могут быть рассмотрены как удовлетворяющие требованиям БЛМ.

Все описанное выше является справедливым для модели БЛМ в "ее классической формулировке", кочующей из книги в книгу и из статьи в статью. Но в оригинальной модели, представленной авторами, было введено требование сильного и слабого спокойствия. Данные требования снимают проблему Z–системы. Рассмотрим их.

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

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

Фактически система Z описывает алгебру моделей, самой строгой из которых (основание) является БЛМ с сильным спокойствием (ни один субъект модели не может изменить свою классификацию), а самой слабой (вершина) -БЛМ в классической формулировке, без ограничений для субъектов на изменение классификации.

12.4. Специализированные модели

Модель MMS

В модели MMS используются следующие понятия.

Классификация –обозначение, накладываемое на информацию, отражающее ущерб, который может быть причинен неавторизованным доступом; включающее уровни: TOP SECRET, SECRET и т.д. и множество меток ("CRYPTO", "NUCLEAR" и т.д.). Множество классификаций и отношение между ними образуют решетку.

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

Пользовательский идентификатор – строка символов, используемая для того, чтобы отметить пользователя системы. Для использования системы пользователь должен предъявить ей пользовательский идентификатор, и система должна провести аутентификацию пользователя. Данная процедура называется login. Каждый пользователь должен иметь уникальный идентификатор.

Пользователь - персона, уполномоченная для использования системы.

Роль –работа, исполняемая пользователем (например, пользователь, имеющий право удалять, распространять или понижать классификацию объектов). Пользователь всегда ассоциирован как минимум с одной ролью в некоторый момент времени, и он может менять роль в течение сессии. Для действий в данной роли пользователь должен быть уполномочен. Некоторые роли могут быть связаны только с одним пользователем в данный момент времени (например, распространитель). С любой ролью связана способность выполнения определенных операций.

Объект – одноуровневый блок информации. Это минимальный блок информации в системе, который имеет классификацию. Объект не содержит других объектов, он не многоуровневый.

Контейнер – многоуровневая информационная структура. Имеет классификацию и может содержать объекты (каждый со своей классификацией) и (или) другие контейнеры. Файл – это контейнер. Некоторые структуры файла могут быть контейнерами. Различие между объектом и контейнером базируется на типе, а не на текущем содержимом: если один из файлов данного типа является контейнером, то все остальные файлы данного типа являются контейнерами, даже если некоторые из них содержат только объекты или пусты. Устройства такие, как диски, принтеры, ленты, сетевые интерфейсы и пользовательские терминалы - контейнеры.

Сущность – Объект или Контейнер.

Требование Степени Доверия Контейнеров – атрибут некоторых контейнеров. Для некоторых контейнеров важно требовать минимум степени доверия, то есть пользователь, не имеющий соответствующего уровня благонадежности, не может просматривать содержимое контейнера. Такие контейнеры помечаются соответствующим атрибутом (CCR). Например, пользователь, имеющий степень доверия CONFIDENTAL, не может просматривать CONFIDENTAL параграф сообщения, помеченного TOP SECRET, если оно содержится в CCR контейнере. Если пользователь должен иметь возможность просматривать данное сообщение, контейнер не должен быть помечен как CCR.

Идентификатор (ID) –имя сущности без ссылки на другие сущности, например, имя файла есть идентификатор этого файла. Обычно все сущности имеют идентификатор.

Ссылка на сущность Прямая, если это идентификатор Сущности.

Ссылка на сущность Косвенная, если это последовательность двух или более имен Сущностей (из которых только первая – идентификатор). Пример – "текущее сообщение, первый абзац, вторая строка".

Операция – функция, которая может быть применена к сущности. Она может позволять просматривать или модифицировать сущность. Некоторые операции могут использовать более одной сущности (пример – операция копирования).

Множество Доступа – множество троек (Пользовательский Идентификатор или Роль, Операция, Индекс операнда), которые связаны с сущностью. Операция, которая может быть специфицирована для особых сущностей, зависит от типа данной сущности. Если операция требует более одного операнда, индекс операнда специфицирует позицию, на которой ссылка на данный операнд может появиться в операции.

Сообщение – особый тип, реализуемый в MMS. Сообщение является контейнером. Сообщение включает поля Куда, Откуда, Время, предмет, текст, автор. Чертежные сообщения включают поле чертежа.

Неформальная модель MMS

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