Файл: Курс лекций по дисциплине Операционные системы 2 Содержание.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 28.03.2024
Просмотров: 49
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Тема: Механизмы защиты
План:
1. Механизмы защиты
1.1. Домены защиты
1.2. Списки управления доступом
1.3. Перечни возможностей
2. Надежные системы
2.1. Высоконадежная вычислительная база
2.2. Формальные модели защищенных систем
2.3. Многоуровневая защита
Литература:
1. Таненбаум Э. Современные операционные системы. – 3-е издание. – СПб.: Питер,
2010. Гл. 1. с. 642-730.
2. Назаров С.В., Гудыно Л.П., Кириченко А.А. Операционные системы. Практикум.
Под ред. С.В. Назарова. – М.: Кудиц-ПРЕСС, 2008. – с. 176-237.
1. Механизмы защиты
В некоторых системах защита реализуется при помощи программы, называющейся
монитором обращений. При каждой попытке доступа к некоторому ресурсу система сначала просит монитор обращений проверить законность данного доступа. Монитор обращений смотрит в таблицы политики и принимает решение. Ниже будет описано окружение, в котором работает монитор обращений.
1.1. Домены защиты
Компьютерная система сдержит множество «объектов», которые требуют защиты.
Это может быть аппаратура (например, ЦП, сегменты памяти, диски или принтеры) или программное обеспечение (например, процессы, файлы, БД и семафоры).
У каждого объекта есть уникальное имя, по которому к нему можно обращаться и набор операций, которые могут выполнять с объектом процессы. Так, например, с файлом могут выполняться операции read и write. Для ограничения доступа к объектам требуется определенный механизм. Более того, этот механизм должен предоставлять возможность не полного запреты доступа, а ограничения в пределах подмножества разрешенных операций.
Чтобы обсудить различные механизмы защиты, полезно ввести концепцию домена. Домен представляет собой множество пар (объект, права доступа). Каждая пара указывает объект и некоторое подмножество операций, которые могут быть с ним выполнены. Права доступа означают в данном контексте разрешение выполнить одну из операций. Домен может соответствовать одному пользователю или группе пользователей.
Рис.1. Три домена защиты
На рис.1. показаны три домена, содержащие объекты и разрешения [RWX – Read,
Write, eXecute – чтение, запись, выполнение] для каждого объекта. Обратим внимание, что
75 объект Printer1 одновременно присутствует в двух доменах. Один и тот объект может иметь в различных доменах разные разрешения.
В каждый момент времени каждый процесс работает в каком-либо одном домене защиты. Другими словами, имеется некоторая коллекция объектов, к которым он может получить доступ, и для каждого объекта у него есть определенный набор разрешений. Во время выполнения процессы имеют право переключаться с одного домена на другой.
Правила переключения между доменами в большой степени зависят от системы.
Чтобы идея домена защиты выглядела более конкретно, рассмотрим пример их для системы UNIX. В UNIX домен процесса определяется его идентификаторами UID и GID процесса. По заданной комбинации (UID, GID) можно составить полный список всех объектов (файлов, включая устройства ввода-вывода, представленные в виде специальных файлов и т.д.), к которым процесс может получить доступ с указанием типа доступа
(чтение, запись, исполнение). Два процесса с одной и той же комбинацией (UID, GID) будут иметь абсолютно одинаковый доступ к одинаковому набору объектов.
Более того, каждый процесс в UNIX состоит их двух частей: пользовательской части и системной части. Когда процесс обращается к системному вызову, он переключается из пользовательской части в системную. Пользовательская и системная части процесса имеют различный доступ к различным множествам объектов. Например, системная часть процесса может иметь доступ ко всем страницам в физической памяти, ко всему диску и ко всем другим защищенным ресурсам. Т.о., системный вызов осуществляет переключение доменов защиты.
Когда процесс выполняет системный вызов exec с файлом, у которого установлен бит SETUID или SETGID, процесс может получить новые идентификаторы UID, GID. При новой комбинации которых процесс получает новый набор доступных файлов и операций.
Запуск программы с установленным битом SETUID или SETGID также представляет собой переключение домена, т.к. права доступа при этом изменяются.
Важным вопросом является то, как система отслеживает, какой объект какому домену принадлежит. Можно себе представить большую матрицу, в которой рядами являются домены, а колонками - объекты. На пересечение располагаются ячейки, содержащие права доступа для данного домена к данному объекту. Например, рис. 2
Рис. 2.
Переключение между доменами также может быть легко реализовано при помощи все той же матрицы, если считать домены объектами, над которыми возможна операция enter (вход).
76
Рис. 3
1.2. Списки управления доступом
На практике, однако, разрешения доступа редко хранятся в виде матрицы, т.к. она была бы очень большой и практически пустой. Поэтому, как правило, такие матрицы хранятся по рядам или столбцам, причем хранятся только непустые элементы. Эти два подхода различаются между собой.
Рассмотрим первый способ. В первом методе с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки, называемые ACL-системами (Access Control
List – список управления доступом), проиллюстрированы на рис.
Рис. Использование ACL-списков для управления доступом к файлам
Здесь мы видим три процесса, принадлежащих различным доменам A, B, и С, а также три файла F1, F2, F3. Для простоты мы будем предполагать, что каждому домену соответствует один пользователь, в данном случае A, B, и С (часто называемые субъектами или принципалами).
С каждым файлом связан ACL-список. У файла F1 в его ACL-списке есть три записи (разделенные символом точка с запятой). В первой записи утверждается, что любой процесс, которым владеет пользователь A, может читать и писать этот файл. Все остальные типы доступа для данных пользователей запрещаются. Всем остальных пользователям запрещен любой доступ к этому файлу. Обратите внимание, что права предоставляются не процессу, а пользователю. Т.о., любой процесс, которым владеет пользователь А, может читать и писать файл F1. Не имеет значения, один такой процесс или их 100. Значение имеет идентификатор владельца, а не процесса.
У файла F2 в его ACL-списке есть три записи пользователи А, В и С могут читать файл, а пользователь В также может писать в него. Другие типы доступа не разрешаются.
Файл F3, по-видимому, представляет собой исполняемую программу, т.к. пользователи А и В могут как читать, так и исполнять его. Пользователю В также разрешается писать в этот файл.
Этот пример иллюстрирует самую общую форму защиты при помощи ACL- списков. Часто на практике используются более сложные системы. Начнем с того, что мы здесь показали только три типа доступа: чтение, запись и исполнение. Кроме них может быть еще много других типов доступа (уничтожение, копирование, добавить сообщение и пр.).
До сих пор мы рассматривали ACL-списки индивидуальных пользователей.
Многими системами поддерживается концепция групп пользователей. У групп есть имена, и они также могут включаться в ACL-списки. Возможно применение двух вариантов семантики групп. Возможно применение двух вариантов семантики групп. В некоторых системах у каждого процесса есть идентификатор пользователя UID и идентификатор группы GID. В других системах ACL-списки содержат записи вида
77
UID1.GID1: права1; UID2.GID2: права2; …
При такой схеме, когда к объекту поступает запрос доступа, выполняется проверка с помощью UID, GID обращаются с запросом процесса. Если они присутствуют в ACL- списке, то перечисленные в списке права предоставляются процессу. Если комбинации
(UID, GID) нет в списке, в доступе к объекту отказывается.
1.3. Перечни возможностей
Матрица, показанная на рис. 3 может также храниться по рядам. При использовании этого метода с каждым процессом ассоциирован список объектов, к которым может быть получен доступ, вместе с информацией о том, какие операции разрешены с каждым объектом, другими словами, доменом защиты объекта. Такой список называется перечнем возможностей, а его элементы называются возможностями. Пример трех процессов и их перечней возможностей показан на рис. 4.
Рис.4. Использование ACL-списков для управления доступом к файлам
Каждый элемент перечня возможностей предоставляет владельцу определенные права по отношению к определенному объекту. Например, процесс, которым владеет пользователь А, может читать файлы F1, F2. Обычно элемент перечня возможностей состоит из идентификатора файла (или, в более общем случае, объекта) и битового массива для различных разрешений. В ОС типа UNIX в качестве идентификатора файла может использоваться номер i-го узла. Перечни возможностей сами являются объектами и на них могут указывать другие перечни возможностей, т.о. облегчая совместное использование субдоменов.
Очевидно, перечни возможностей должны быть защищены от искажения их пользователями. Известны три типа способа их защиты. Для первого способа требуется теговая архитектура, т.е. аппаратно реализованная структура памяти, в которой у каждого слова памяти есть дополнительный (теговый) бит, сообщающий, содержит ли данное слово памяти элемент перечня возможностей или нет. Теговый бит не используется в обычных командах процессора, таких как арифметические или команды сравнения.
Изменен он может быть только программой, работающей в режиме ядра (т.е. ОС).
Второй способ состоит в том, что перечень возможностей хранится внутри ОС.
При этом к элементам перечня возможностей можно обращаться по их позиции в перечне.
При этом к элементам перечня возможностей можно обращаться по их позиции в перечне.
Третий способ заключается в хранении перечня возможностей в пространстве пользователя, но в защищенном виде, так чтобы пользователь не смог изменить эту информацию. Этот метод хорошо подходит для распределенных систем и работает следующим образом. Когда клиентский процесс отправляет сообщение удаленному серверу, например, файловому серверу, чтобы создать объект для него, сервер создает объект, а также формирует большое случайное число, используемое как контрольное поле. В таблице файлового сервера для объекта резервируется запись, в которой также хранится контрольное поле, адреса дисковых блоков и т.д.В терминах системы UNIX
78 контрольное поле хранится на сервере в i-узле. Оно не посылается пользователю и вообще никогда не попадает в сеть. Затем сервер формирует и передает пользователю элемент перечня возможностей, формат которого показан на рис.
Рис. Элемент перечня возможностей, защищенный с помощью шифрования
Помимо специфических разрешений, зависящих от конкретного объекта, например чтение и исполнение, элементы перечня возможностей (как системные, так и защищенные шифрованием) содержат, как правило, общие права, то есть разрешения выполнения действий, применимых ко всем объектам. Примерами таких действий являются:
1. Копирование элемента перечня возможностей: создание нового элемента перечня возможностей для того же объекта.
2. Копирование объекта: создание дубликата объекта с новым элементом перечня возможностей.
3. Удаление элемента перечня возможностей: удаление записи в перечне возможностей; объект при этом не затрагивается.
4. Удаление объекта: удаление объекта и элемента перечня возможностей.
2. Надежные системы
Для построения защищенной системы следует использовать в ядре ОС модель безопасности, достаточно простую, чтобы разработчики были способны еѐ понять, а также следует сопротивляться давлению отойти от используемой модели под предлогом добавления в систему новых функций.
2.1. Высоконадежная вычислительная база
Надежная система – это система, в которой формально установлены требования безопасности и которая удовлетворяет этим требованиям. В сердце каждой надежной системы находится минимальная база TCB (Trusted Computing Base – высоконадежная вычислительная база), состоящая из аппаратного ПО, необходимого для проведения в жизнь всех правил безопасности. Если высоконадежная вычислительная база работает в соответствии с техническими условиями, безопасность системы не может быть нарушена независимо от любых других обстоятельств.
ТСВ, как правило, состоит из большей части аппаратного обеспечения (кроме устройств ввода-вывода, не влияющих на безопасность), части ядра ОС и большей части или всех пользовательских программ, обладающих полномочиями суперпользователя
(например, программы с установленным битом SETUID, владельцем которых является root в системе UNIX). К функциям ОС, которые должны быть частью ТСВ, относятся создание процесса, переключение процессов, управление картой памяти, а также часть файлового управления и управления вводом-выводом. В надежных системах база ТСВ часто представляет собой совершенно отдельную ото всей остальной ОС, что позволяет уменьшить еѐ размеры и проверить корректность работы.
Важную часть высоконадежной вычислительной базы составляет монитор обращений, как показано на рис.
79
Рис. Монитор обращений
Монитор обращений принимает все системные вызовы, имеющие отношение к безопасности, такие как открытие файлов, и принимает решение, следует их выполнять или нет. Т.о., монитор обращений позволяет все решения о безопасности поместить в одном месте, не предоставляя возможностей обойти их. Организация большинства ОС отличается от данной схемы, в чем заключается одна из причин их ненадежности.
2.2. Формальные модели защищенных систем
Матрицы защиты не статичны. Они часто меняются с созданием новых объектов, удалением старых объектов, а также когда владельцы объектов решают расширить или ограничить набор разрешений или круг пользователей, которым предоставляется доступ к объекту. Значительное внимание было уделено моделированию систем защиты, в которых матрицы защиты постоянно меняются. Рассмотрим некоторые из этих исследовательских работ.
Харрисон и его коллеги определили шесть примитивных операций на матрицей защиты, которые могут использоваться как основа моделирования любой системы защиты. Эти примитивные операции представляют собой создать объект, удалить объект, создать домен, удалить домен, добавить разрешение и удалить разрешение.
Эти шесть примитивов можно объединить в команды защиты, которые могут выполняться программами пользователя для изменения матрицы. Пользовательские программы не могут напрямую выполнить примитивы. Например, в системе может быть команда для создания нового файла, которая проверяет, существует ли уже этот файл, и если нет, создает новый объект и предоставляет владельцу все права к нему. Также может команда, позволяющая владельцу файла передать права чтения этого файла любому другому пользователю, для чего в каждый домен вставляется запись, дающая право чтения этого файла.
2.3. Многоуровневая защита
Большинство ОС позволяют индивидуальным пользователям определять, кто может читать и писать их файлы, а также иметь доступ к другим их объектам. Такая политика называется дискреционным управлением доступом. Во многих окружениях эта модель прекрасно работает, но существуют среды, в которых необходимы значительно более жесткие требования к безопасности, как, например, в воинских частях, патентных отделах корпораций и больницах. В этих системах организации устанавливают правила, определяющие, кто и что может видеть, и эти правила не могут изменять солдаты, юристы или врачи, по крайней мере, без специального разрешения от своего начальства. Для таких
План:
1. Механизмы защиты
1.1. Домены защиты
1.2. Списки управления доступом
1.3. Перечни возможностей
2. Надежные системы
2.1. Высоконадежная вычислительная база
2.2. Формальные модели защищенных систем
2.3. Многоуровневая защита
Литература:
1. Таненбаум Э. Современные операционные системы. – 3-е издание. – СПб.: Питер,
2010. Гл. 1. с. 642-730.
2. Назаров С.В., Гудыно Л.П., Кириченко А.А. Операционные системы. Практикум.
Под ред. С.В. Назарова. – М.: Кудиц-ПРЕСС, 2008. – с. 176-237.
1. Механизмы защиты
В некоторых системах защита реализуется при помощи программы, называющейся
монитором обращений. При каждой попытке доступа к некоторому ресурсу система сначала просит монитор обращений проверить законность данного доступа. Монитор обращений смотрит в таблицы политики и принимает решение. Ниже будет описано окружение, в котором работает монитор обращений.
1.1. Домены защиты
Компьютерная система сдержит множество «объектов», которые требуют защиты.
Это может быть аппаратура (например, ЦП, сегменты памяти, диски или принтеры) или программное обеспечение (например, процессы, файлы, БД и семафоры).
У каждого объекта есть уникальное имя, по которому к нему можно обращаться и набор операций, которые могут выполнять с объектом процессы. Так, например, с файлом могут выполняться операции read и write. Для ограничения доступа к объектам требуется определенный механизм. Более того, этот механизм должен предоставлять возможность не полного запреты доступа, а ограничения в пределах подмножества разрешенных операций.
Чтобы обсудить различные механизмы защиты, полезно ввести концепцию домена. Домен представляет собой множество пар (объект, права доступа). Каждая пара указывает объект и некоторое подмножество операций, которые могут быть с ним выполнены. Права доступа означают в данном контексте разрешение выполнить одну из операций. Домен может соответствовать одному пользователю или группе пользователей.
Рис.1. Три домена защиты
На рис.1. показаны три домена, содержащие объекты и разрешения [RWX – Read,
Write, eXecute – чтение, запись, выполнение] для каждого объекта. Обратим внимание, что
75 объект Printer1 одновременно присутствует в двух доменах. Один и тот объект может иметь в различных доменах разные разрешения.
В каждый момент времени каждый процесс работает в каком-либо одном домене защиты. Другими словами, имеется некоторая коллекция объектов, к которым он может получить доступ, и для каждого объекта у него есть определенный набор разрешений. Во время выполнения процессы имеют право переключаться с одного домена на другой.
Правила переключения между доменами в большой степени зависят от системы.
Чтобы идея домена защиты выглядела более конкретно, рассмотрим пример их для системы UNIX. В UNIX домен процесса определяется его идентификаторами UID и GID процесса. По заданной комбинации (UID, GID) можно составить полный список всех объектов (файлов, включая устройства ввода-вывода, представленные в виде специальных файлов и т.д.), к которым процесс может получить доступ с указанием типа доступа
(чтение, запись, исполнение). Два процесса с одной и той же комбинацией (UID, GID) будут иметь абсолютно одинаковый доступ к одинаковому набору объектов.
Более того, каждый процесс в UNIX состоит их двух частей: пользовательской части и системной части. Когда процесс обращается к системному вызову, он переключается из пользовательской части в системную. Пользовательская и системная части процесса имеют различный доступ к различным множествам объектов. Например, системная часть процесса может иметь доступ ко всем страницам в физической памяти, ко всему диску и ко всем другим защищенным ресурсам. Т.о., системный вызов осуществляет переключение доменов защиты.
Когда процесс выполняет системный вызов exec с файлом, у которого установлен бит SETUID или SETGID, процесс может получить новые идентификаторы UID, GID. При новой комбинации которых процесс получает новый набор доступных файлов и операций.
Запуск программы с установленным битом SETUID или SETGID также представляет собой переключение домена, т.к. права доступа при этом изменяются.
Важным вопросом является то, как система отслеживает, какой объект какому домену принадлежит. Можно себе представить большую матрицу, в которой рядами являются домены, а колонками - объекты. На пересечение располагаются ячейки, содержащие права доступа для данного домена к данному объекту. Например, рис. 2
Рис. 2.
Переключение между доменами также может быть легко реализовано при помощи все той же матрицы, если считать домены объектами, над которыми возможна операция enter (вход).
76
Рис. 3
1.2. Списки управления доступом
На практике, однако, разрешения доступа редко хранятся в виде матрицы, т.к. она была бы очень большой и практически пустой. Поэтому, как правило, такие матрицы хранятся по рядам или столбцам, причем хранятся только непустые элементы. Эти два подхода различаются между собой.
Рассмотрим первый способ. В первом методе с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки, называемые ACL-системами (Access Control
List – список управления доступом), проиллюстрированы на рис.
Рис. Использование ACL-списков для управления доступом к файлам
Здесь мы видим три процесса, принадлежащих различным доменам A, B, и С, а также три файла F1, F2, F3. Для простоты мы будем предполагать, что каждому домену соответствует один пользователь, в данном случае A, B, и С (часто называемые субъектами или принципалами).
С каждым файлом связан ACL-список. У файла F1 в его ACL-списке есть три записи (разделенные символом точка с запятой). В первой записи утверждается, что любой процесс, которым владеет пользователь A, может читать и писать этот файл. Все остальные типы доступа для данных пользователей запрещаются. Всем остальных пользователям запрещен любой доступ к этому файлу. Обратите внимание, что права предоставляются не процессу, а пользователю. Т.о., любой процесс, которым владеет пользователь А, может читать и писать файл F1. Не имеет значения, один такой процесс или их 100. Значение имеет идентификатор владельца, а не процесса.
У файла F2 в его ACL-списке есть три записи пользователи А, В и С могут читать файл, а пользователь В также может писать в него. Другие типы доступа не разрешаются.
Файл F3, по-видимому, представляет собой исполняемую программу, т.к. пользователи А и В могут как читать, так и исполнять его. Пользователю В также разрешается писать в этот файл.
Этот пример иллюстрирует самую общую форму защиты при помощи ACL- списков. Часто на практике используются более сложные системы. Начнем с того, что мы здесь показали только три типа доступа: чтение, запись и исполнение. Кроме них может быть еще много других типов доступа (уничтожение, копирование, добавить сообщение и пр.).
До сих пор мы рассматривали ACL-списки индивидуальных пользователей.
Многими системами поддерживается концепция групп пользователей. У групп есть имена, и они также могут включаться в ACL-списки. Возможно применение двух вариантов семантики групп. Возможно применение двух вариантов семантики групп. В некоторых системах у каждого процесса есть идентификатор пользователя UID и идентификатор группы GID. В других системах ACL-списки содержат записи вида
77
UID1.GID1: права1; UID2.GID2: права2; …
При такой схеме, когда к объекту поступает запрос доступа, выполняется проверка с помощью UID, GID обращаются с запросом процесса. Если они присутствуют в ACL- списке, то перечисленные в списке права предоставляются процессу. Если комбинации
(UID, GID) нет в списке, в доступе к объекту отказывается.
1.3. Перечни возможностей
Матрица, показанная на рис. 3 может также храниться по рядам. При использовании этого метода с каждым процессом ассоциирован список объектов, к которым может быть получен доступ, вместе с информацией о том, какие операции разрешены с каждым объектом, другими словами, доменом защиты объекта. Такой список называется перечнем возможностей, а его элементы называются возможностями. Пример трех процессов и их перечней возможностей показан на рис. 4.
Рис.4. Использование ACL-списков для управления доступом к файлам
Каждый элемент перечня возможностей предоставляет владельцу определенные права по отношению к определенному объекту. Например, процесс, которым владеет пользователь А, может читать файлы F1, F2. Обычно элемент перечня возможностей состоит из идентификатора файла (или, в более общем случае, объекта) и битового массива для различных разрешений. В ОС типа UNIX в качестве идентификатора файла может использоваться номер i-го узла. Перечни возможностей сами являются объектами и на них могут указывать другие перечни возможностей, т.о. облегчая совместное использование субдоменов.
Очевидно, перечни возможностей должны быть защищены от искажения их пользователями. Известны три типа способа их защиты. Для первого способа требуется теговая архитектура, т.е. аппаратно реализованная структура памяти, в которой у каждого слова памяти есть дополнительный (теговый) бит, сообщающий, содержит ли данное слово памяти элемент перечня возможностей или нет. Теговый бит не используется в обычных командах процессора, таких как арифметические или команды сравнения.
Изменен он может быть только программой, работающей в режиме ядра (т.е. ОС).
Второй способ состоит в том, что перечень возможностей хранится внутри ОС.
При этом к элементам перечня возможностей можно обращаться по их позиции в перечне.
При этом к элементам перечня возможностей можно обращаться по их позиции в перечне.
Третий способ заключается в хранении перечня возможностей в пространстве пользователя, но в защищенном виде, так чтобы пользователь не смог изменить эту информацию. Этот метод хорошо подходит для распределенных систем и работает следующим образом. Когда клиентский процесс отправляет сообщение удаленному серверу, например, файловому серверу, чтобы создать объект для него, сервер создает объект, а также формирует большое случайное число, используемое как контрольное поле. В таблице файлового сервера для объекта резервируется запись, в которой также хранится контрольное поле, адреса дисковых блоков и т.д.В терминах системы UNIX
78 контрольное поле хранится на сервере в i-узле. Оно не посылается пользователю и вообще никогда не попадает в сеть. Затем сервер формирует и передает пользователю элемент перечня возможностей, формат которого показан на рис.
Рис. Элемент перечня возможностей, защищенный с помощью шифрования
Помимо специфических разрешений, зависящих от конкретного объекта, например чтение и исполнение, элементы перечня возможностей (как системные, так и защищенные шифрованием) содержат, как правило, общие права, то есть разрешения выполнения действий, применимых ко всем объектам. Примерами таких действий являются:
1. Копирование элемента перечня возможностей: создание нового элемента перечня возможностей для того же объекта.
2. Копирование объекта: создание дубликата объекта с новым элементом перечня возможностей.
3. Удаление элемента перечня возможностей: удаление записи в перечне возможностей; объект при этом не затрагивается.
4. Удаление объекта: удаление объекта и элемента перечня возможностей.
2. Надежные системы
Для построения защищенной системы следует использовать в ядре ОС модель безопасности, достаточно простую, чтобы разработчики были способны еѐ понять, а также следует сопротивляться давлению отойти от используемой модели под предлогом добавления в систему новых функций.
2.1. Высоконадежная вычислительная база
Надежная система – это система, в которой формально установлены требования безопасности и которая удовлетворяет этим требованиям. В сердце каждой надежной системы находится минимальная база TCB (Trusted Computing Base – высоконадежная вычислительная база), состоящая из аппаратного ПО, необходимого для проведения в жизнь всех правил безопасности. Если высоконадежная вычислительная база работает в соответствии с техническими условиями, безопасность системы не может быть нарушена независимо от любых других обстоятельств.
ТСВ, как правило, состоит из большей части аппаратного обеспечения (кроме устройств ввода-вывода, не влияющих на безопасность), части ядра ОС и большей части или всех пользовательских программ, обладающих полномочиями суперпользователя
(например, программы с установленным битом SETUID, владельцем которых является root в системе UNIX). К функциям ОС, которые должны быть частью ТСВ, относятся создание процесса, переключение процессов, управление картой памяти, а также часть файлового управления и управления вводом-выводом. В надежных системах база ТСВ часто представляет собой совершенно отдельную ото всей остальной ОС, что позволяет уменьшить еѐ размеры и проверить корректность работы.
Важную часть высоконадежной вычислительной базы составляет монитор обращений, как показано на рис.
79
Рис. Монитор обращений
Монитор обращений принимает все системные вызовы, имеющие отношение к безопасности, такие как открытие файлов, и принимает решение, следует их выполнять или нет. Т.о., монитор обращений позволяет все решения о безопасности поместить в одном месте, не предоставляя возможностей обойти их. Организация большинства ОС отличается от данной схемы, в чем заключается одна из причин их ненадежности.
2.2. Формальные модели защищенных систем
Матрицы защиты не статичны. Они часто меняются с созданием новых объектов, удалением старых объектов, а также когда владельцы объектов решают расширить или ограничить набор разрешений или круг пользователей, которым предоставляется доступ к объекту. Значительное внимание было уделено моделированию систем защиты, в которых матрицы защиты постоянно меняются. Рассмотрим некоторые из этих исследовательских работ.
Харрисон и его коллеги определили шесть примитивных операций на матрицей защиты, которые могут использоваться как основа моделирования любой системы защиты. Эти примитивные операции представляют собой создать объект, удалить объект, создать домен, удалить домен, добавить разрешение и удалить разрешение.
Эти шесть примитивов можно объединить в команды защиты, которые могут выполняться программами пользователя для изменения матрицы. Пользовательские программы не могут напрямую выполнить примитивы. Например, в системе может быть команда для создания нового файла, которая проверяет, существует ли уже этот файл, и если нет, создает новый объект и предоставляет владельцу все права к нему. Также может команда, позволяющая владельцу файла передать права чтения этого файла любому другому пользователю, для чего в каждый домен вставляется запись, дающая право чтения этого файла.
2.3. Многоуровневая защита
Большинство ОС позволяют индивидуальным пользователям определять, кто может читать и писать их файлы, а также иметь доступ к другим их объектам. Такая политика называется дискреционным управлением доступом. Во многих окружениях эта модель прекрасно работает, но существуют среды, в которых необходимы значительно более жесткие требования к безопасности, как, например, в воинских частях, патентных отделах корпораций и больницах. В этих системах организации устанавливают правила, определяющие, кто и что может видеть, и эти правила не могут изменять солдаты, юристы или врачи, по крайней мере, без специального разрешения от своего начальства. Для таких
