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

5.5.3. Мандаты

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

Типичный пример списка полномочий приведен в табл. 5.3. У каждого мандата есть поле Туре, сообщающее тип объекта, поле Rights, являющееся битовой картой, описывающей допустимые для данного типа объектов операции, и поле Object, содержащее указатель на сам объект (например, номер его г-узла). Списки полномочий сами являются объектами, на которые позволено ссылаться из других списков, тем самым упрощается совместное использование поддоменов. На мандаты часто ссылаются по номеру в перечне. Например, процесс может сказать что-нибудь вроде: прочитать 1 Кбайт из файла, на который ссылается мандат 2 . Такой способ адресации подобен тому, как в UNIX используются дескрипторы.

Таблица 5.3. Список полномочий для домена 2 на рис. 5.21

Очевидно, что списки полномочий (или, как они сокращенно называются, С-списки) должны быть защищены от искажения их пользователями. Известны три способа защиты. Для первого требуется теговая архитектура, то есть аппаратно реализованная структура памяти, в которой у каждого слова памяти есть дополнительный (теговый) бит, сообщающий, содержит ли данное слово памяти мандат или нет. Теговый бит не используется в обычных командах процессора, таких как арифметические или команды сравнения. Изменен он может быть только программой, работающей в режиме ядра (то есть операционной системой).

Особенность второго способа в том, что список хранится внутри операционной системы. При этом к элементам списка можно обращаться по их позиции в списке. Такая форма адресации также напоминает использование дескрипторов файла в UNIX. Именно таким образом работала система Hydra [88].

Третий способ заключается в хранении списка мандатов в пространстве пользователя, но в зашифрованном виде, так, чтобы пользователь не сумел изменить эту информацию. Эта схема была разработана для распределенной операционной системы Amoeba и активно в ней применялась [81].

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

♦ копирование элемента списка: создание нового элемента для того же объекта;

♦ копирование объекта: создание дубликата объекта с новым мандатом;

♦ удаление элемента списка: удаление записи в нем, объект при этом не затрагивается;

♦ удаление объекта: удаление объекта и элемента списка.

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

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

5.5.4. Секретные каналы

Даже в корректно реализованной системе, в основе которой лежит правильная модель безопасности и безопасность которой была доказана, не исключены проколы защиты. В данном разделе мы обсудим, как информация может утекать на сторону даже в системах, для которых строго математически было доказано, что подобные утечки невозможны. Идеи, изложенные ниже, были высказаны Лэмп-соном в [52].

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

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

Третий процесс, называемый в данной модели сообщником (буквально collaborator, то есть партнер ), намеревается украсть конфиденциальные сведения клиента. Владельцем этого процесса и сервера, как правило, является один и тот же человек. Все три процесса показаны на рис. 5.23. Цель данной модели - помочь разработать систему, в которой невозможна утечка информации, полученной сервером у клиента, к процессу- подельнику . Лэмпсон назвал это проблемой ограждения.

Клиент Сервер Сообщник

Ядро

Инкапсулированный сервер

Тайный канал

Рис. 5.23. а - клиент, сервер и сообщник ; 6 - от инкапсулированного сервера информация все равно может утекать сообщнику по тайному каналу

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

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

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

Модуляция не является единственным вариантом тайного канала. Информация также может кодироваться страничными прерываниями, например, много прерываний в течение определенного интервала времени будет означать 1,