Добавлен: 29.10.2018
Просмотров: 48144
Скачиваний: 190
676
Глава 9. Безопасность
при наличии хорошей односторонней функции даже самый настойчивый взломщик
не сможет разгадать содержимое контрольного поля, даже если ему будет известно
содержимое всех остальных полей возможности.
Когда пользователь хочет получить доступ к объекту, он отправляет элемент перечня
возможностей серверу в своем запросе. Сервер извлекает из него номер объекта и ис-
пользует его в качестве индекса для поиска объекта в своих таблицах. Затем он вычис-
ляет f(Objects, Rights, Check), взяв первые два параметра для этой функции из прислан-
ного ему пользователем элемента перечня возможностей, а третий параметр — из своих
таблиц. Если результат совпадает с четвертым полем элемента перечня возможностей,
запрос удовлетворяется, в противном случае он отклоняется. Если пользователь пы-
тается получить доступ к чужому объекту, он не сможет подделать четвертое поле, так
как не знает значения контрольного поля, и его запрос будет отклонен.
Пользователь может потребовать у сервера создания элемента перечня возможностей
с меньшими правами, например позволяющего только читать объект. Первым делом
сервер проверяет достоверность элемента перечня возможностей. Если проверка про-
ходит успешно, он вычисляет f(Objects, New_rights, Check) и создает новый элемент
перечня возможностей, помещая полученное значение в четвертое поле. Обратите вни-
мание на то, что при этом используется исходное значение контрольного поля Check,
поскольку от него зависят другие, неизмененные элементы перечня возможностей.
Этот новый элемент перечня возможностей отправляется обратно запрашивающему
процессу. Теперь пользователь может передать его своему другу, отправив, к примеру,
этот элемент в сообщении. Если друг попытается включить какой-нибудь бит прав,
который должен быть выключен, сервер обнаружит это при попытке воспользоваться
возможностью, поскольку значение функции f не будет соответствовать сфальси-
фицированному полю прав. Поскольку другу не известно значение поля проверки
достоверности, он не сможет подделать элемент перечня возможностей так, чтобы тот
соответствовал фальсифицированным битам прав. Эта схема была разработана для
распределенной операционной системы Amoeba (Tanenbaum et al., 1990).
Вдобавок к специфическим правам, зависящим от характера объекта, таким как право
на чтение и исполнение, элементы перечня возможностей (как содержащиеся в ядре,
так и защищенные шифрованием) содержат, как правило, общие права (generic rights),
применимые ко всем объектам. Примерами общих прав являются:
копирование элемента возможностей — создание нового элемента для того же
самого объекта;
копирование объекта — создание дубликата объекта с новым элементом возмож-
ностей;
удаление элемента возможностей — удаление записи из перечня возможностей без
оказания какого-либо влияния на объект;
удаление объекта — полное удаление объекта и связанных с ним возможностей.
И последнее замечание, которое стоит сделать относительно систем перечней воз-
можностей, касается того, что в версии, управляемой на уровне ядра, отмена доступа
к объекту сильно затруднена. Системе трудно найти все незадействованные элементы
возможностей для какого-нибудь объекта, чтобы их отобрать, поскольку они могут хра-
ниться в перечнях возможностей, размещенных в разных местах по всему диску. Один
из подходов заключается в том, чтобы каждая возможность указывала на косвенный
9.4. Формальные модели систем безопасности
677
объект, а не на сам объект как таковой. При наличии косвенного объекта, указывающего
на реальный объект, система всегда может разорвать эту связь, аннулируя возможности.
(Впоследствии, когда элемент перечня возможностей в отношении косвенного объекта
будет представлен системе, пользователь обнаружит, что теперь косвенный объект
указывает на нулевой объект.)
В системе Amoeba отмена доступа выполняется довольно легко. Для этого нужно лишь
изменить контрольное поле, хранящееся вместе с объектом. Все существующие воз-
можности аннулируются одним махом. Тем не менее ни одна из схем не обеспечивает
выборочного аннулирования прав, то есть невозможно, например, аннулировать права
Джона, не затронув прав всех остальных пользователей. Этот недостаток относится ко
всем системам, использующим перечни возможностей.
Еще одной общей проблемой является гарантия того, что владелец достоверного элемен-
та перечня возможностей не раздаст его копию тысяче своих лучших друзей. Эта пробле-
му можно решить в таких системах, как Hydra, где перечнями возможностей управляет
ядро, но подобное решение не работает в распределенных системах, таких как Amoeba.
Если кратко подвести итоги, то ACL-списки и перечни возможностей обладают отчасти
взаимодополняющими свойствами. Перечням возможностей свойственна высокая
эффективность, поскольку если процесс требует «открыть файл, на который указывает
элемент возможностей 3», проверка не требуется. Если группы не поддерживаются,
то предоставление всем прав на доступ к чтению файла требует перечисления всех
пользователей в ACL-списке. Перечни возможностей, в отличие от ACL-списков, также
позволяют процессу легко инкапсулироваться. В то же время ACL-списки, в отличие от
перечней возможностей, позволяют выборочно отзывать права. И наконец, если объект
удаляется, а перечень возможностей — нет или наоборот, возникают проблемы. При
использовании ACL-списков эти проблемы отсутствуют.
С ACL-списками знакомо большинство пользователей, поскольку они встречаются
в Windows и UNIX. А вот перечни возможностей не столь популярны. Например,
ядро L4, работающее на многих смартфонах от множества производителей (обычно под
управлением Android), основано на использовании перечней возможностей. В FreeBSD
также имеется включение Capsicum, добавляющее перечни возможностей в популяр-
ного представителя семейства UNIX.
9.4. Формальные модели систем безопасности
Матрицы защиты вроде той, что показана на рис. 9.3, не являются статичными. Они
часто подвергаются изменениям при создании новых объектов, уничтожении старых
объектов и принятии решения владельцами о расширении или сужении круга тех, кто
пользуется их объектами.
Большое внимание уделялось моделированию систем защиты с постоянно изменяю-
щейся матрицей защиты. Теперь мы кратко рассмотрим некоторые из этих работ. Не-
сколько десятилетий назад были определены (Harrison et al., 1976) шесть элементарных
операций (примитивов) в матрице защиты, которые могут послужить основой модели
любой системы защиты. Этими элементарными операциями были создание объекта,
удаление объекта, создание домена, удаление домена, вставка права и удаление права.
Два последних примитива касались вставки и удаления прав из определенных записей
матрицы, например предоставления домену 1 разрешения на чтение файла
File6
.
678
Глава 9. Безопасность
Эти шесть элементарных операций могли объединяться в команды защиты (protection
commands). Именно эти команды защиты пользовательские программы могут выпол-
нять для изменения матрицы. Они могут и не выполнять примитивы непосредственно.
Например, у системы может быть команда для создания нового файла, которая будет
проверять, не существует ли уже такой файл, и если его не существует, создавать
новый объект и предоставлять владельцу все права на этот объект. Это также может
быть команда, позволяющая владельцу предоставлять права на чтение файла любому
присутствующему в системе, которая на самом деле вставляет право read (чтение)
в запись, созданную для нового файла в каждом домене.
В любой момент времени согласно матрице определяется, что процесс в любом домене
может делать, а не на что ему были предоставлены права. Матрица ведется системой,
а предоставление прав должно относиться к политике управления. Чтобы привести
пример этого различия, рассмотрим простую систему, показанную на рис. 9.8, где до-
мены соотносятся с пользователями. На рис. 9.8, а, показана намеченная политика
защиты: Генри может проводить с
mailbox7
операции чтения и записи, Роберт может
читать и записывать данные в файл
secret
, и все три пользователя могут читать и за-
пускать на выполнение файл
compiler
.
Теперь представим себе, что Роберт настолько умен, что нашел способ выдачи команды
на изменение матрицы и привел ее в состояние, показанное на рис. 9.8, б. Теперь он
получил доступ к
mailbox7
, который ранее не был санкционирован. При попытке чтения
этого объекта операционная система выполнит его запрос, поскольку она не знает, что
состояние, показанное на рис. 9.8, б, является несанкционированным.
Рис. 9.8. Состояние: а — санкционированное; б — несанкционированное
Теперь должно быть понятно, что множество всех возможных матриц должно быть
разделено на два разобщенных подмножества: подмножество санкционированных со-
стояний и подмножество несанкционированных состояний.
Вопрос, вокруг которого могут выстраиваться теоретические исследования, форму-
лируется следующим образом: можно ли утверждать, что при наличии начального
санкционированного состояния и набора команд система никогда не сможет попасть
в несанкционированное состояние?
По сути, вопрос состоит в том, может ли имеющийся в распоряжении механизм
(коман ды защиты) в достаточной степени ввести в действие некую политику защиты.
Имея политику, некое исходное состояние матрицы и набор команд для ее изменения,
мы должны получить способ, позволяющий удостовериться в безопасности системы.
9.4. Формальные модели систем безопасности
679
Оказывается, получить подобное доказательство очень трудно. Многие универсальные
системы теоретически не обладают безопасностью. В работе Harrison et al. (1976) было
доказано, что в случае произвольной конфигурации для любой системы защиты без-
опасность теоретически недостижима. Тем не менее для определенной системы можно
доказать, может ли система когда-либо перейти из санкционированного в несанкциони-
рованное состояние. Дополнительная информация доступна в работе Landwehr (1981).
9.4.1. Многоуровневая защита
Большинство операционных систем позволяют отдельным пользователям определять,
кто может читать и записывать их файлы и другие объекты. Такая политика называется
разграничительным управлением доступом
(discretional access control)
1
. Во многих
средах эта модель работает неплохо, но существуют и другие среды, в которых необ-
ходимы значительно более жесткие меры безопасности. К их числу относятся военные
организации, корпоративные патентные отделы и лечебные учреждения. В этих органи-
зациях устанавливаются правила, определяющие, кто и что может просматривать, и эти
правила не могут изменять отдельные сотрудники, юристы или врачи, по крайней мере
без специального разрешения от своего начальства (или, возможно, тех лиц, которые
находятся на одном уровне с этим начальством). Для таких сред, помимо стандартного
разграничительного управления доступом, требуется принудительное управление до-
ступом
(mandatory access control)
2
, чтобы гарантировать, что установленная политика
безопасности реализуется системой. Принудительное управление доступом регулирует
поток информации, гарантируя отсутствие непредвиденной ее утечки.
Модель Белла — Лападулы
Наиболее широкое распространение среди моделей многоуровневой защиты получила
модель Белла — Лападулы
(Bell — LaPadula model), поэтому она и будет рассмотрена
в первую очередь (Bell and LaPadula, 1973). Эта модель была разработана для обе-
спечения военной системы безопасности, но она подходит и для других организаций.
У военных документы (объекты) должны обладать грифом секретности, например: «не-
секретный», «для служебного пользования», «секретный» и «совершенно секретный».
Люди также получают форму допуска, определяющую, какие документы им разрешено
просматривать. Генералу может быть разрешено просматривать все документы, а лейте-
нант может иметь допуск к просмотру лишь документов с грифом «секретно» и ниже.
Процесс, принадлежащий пользователю, приобретает его уровень безопасности. Так
как уровней безопасности несколько, такая схема называется многоуровневой систе-
мой безопасности
(multilevel security system).
Модель Белла — Лападулы имеет следующие правила организации информационного
потока.
1
В литературе также встречаются следующие названия (варианты перевода): «избирательное
управление доступом», «контролируемое управление доступом», «дискреционное управле-
ние доступом». — Примеч. ред.
2
В литературе также встречаются следующие названия (варианты перевода): «мандатное
управление доступом» и «полномочное управление доступом». При этом одни авторы рас-
сматривают их как синонимы, другие считают их сходными, но различными понятиями. —
Примеч. ред.
680
Глава 9. Безопасность
1. Простое свойство безопасности (The simple security property) — процесс, за-
пущенный на уровне безопасности k, может проводить операцию чтения только
в отношении объектов своего или более низкого уровня. К примеру, генерал мо-
жет читать документы лейтенанта, но лейтенант не может читать генеральские
документы.
2. Свойство * (The * property) — процесс, работающий на уровне безопасности k, мо-
жет вести запись только в объекты своего или более высокого уровня. К примеру,
лейтенант может добавить сообщение в генеральский почтовый ящик, докладывая
обо всем, что ему известно, но генерал не может добавить сообщение в лейтенант-
ский почтовый ящик, сообщая о том, что известно ему, поскольку генерал может
быть ознакомлен с совершенно секретными документами, содержание которых не
должно доводиться до лейтенанта.
Кратко подытоживая: процессы могут осуществлять чтение вниз и запись наверх, но
не наоборот. Если система четко соблюдает эти два свойства, то можно показать, что
утечки информации с более безопасного уровня на менее безопасный не будет. Свой-
ство * получило такое название потому, что в исходном тексте своего доклада авторы
не смогли придумать для него подходящего названия и временно, до тех пор, пока не
придумают что-либо стоящее, на его место поставили символ *. Но свое намерение они
так и не осуществили, и доклад был распечатан с символом звездочки. В этой модели
процессы осуществляют операции чтения и записи в отношении объектов, но напря-
мую друг с другом не общаются. Графическое представление модели Белла — Лападулы
показано на рис. 9.9.
Рис. 9.9. Многоуровневая модель безопасности Белла — Лападулы
На этом рисунке сплошная стрелка от объекта к процессу показывает, что процесс
осуществляет чтение объекта, то есть информационный поток идет от объекта к про-
цессу. По аналогии с этим пунктирная стрелка от процесса к объекту показывает, что
процесс осуществляет запись в объект, то есть информационный поток идет от про-
цесса к объекту. Таким образом, информационные потоки следуют по направлениям,