Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
Механизмы защиты
Предлагаем Вашему вниманию
главу из книги Э.═Таненбаума
╚Современные операционные системы╩.
Компьютерная система содержит множество ╚объектов╩, которые требуется защищать. Это может быть аппаратура (например, центральный процессор, сегменты памяти, диски или принтеры) или программное обеспечение (например, процессы, файлы, базы данных или семафоры).
У каждого объекта есть уникальное имя, по которому к нему можно обращаться, и набор операций, которые могут выполнять с объектом процессы. Так, с файлом могут выполняться операции read и write, с семафором имеют смысл операции up и down.
Очевидно, что для ограничения доступа к объектам требуется определенный механизм. Более того, этот механизм должен предоставлять возможность не полного запрета доступа, а ограничения в пределах подмножества разрешенных операций. Например, процессу═A может быть разрешено читать, но не писать файл═F.
Чтобы обсудить различные механизмы защиты, полезно ввести концепцию домена. Домен представляет собой множество пар (объект, права доступа). Каждая пара указывает объект и некоторое подмножество операций, которые могут быть с ним выполнены. Права доступа означают в данном контексте разрешение выполнить одну из операций. Домен может соответствовать одному пользователю или группе пользователей.
На рисунке 1 показаны три домена, содержащие объекты и разрешения [RWX═≈ Read, Write, eXecute═≈ чтение, запись, выполнение] для каждого объекта. Обратите внимание, что объект Принтер1 одновременно присутствует в двух доменах. Хотя это и не изображено в данном примере, один и тот же объект может иметь в различных доменах разные разрешения.
Рис.═1.═Три домена защиты
В каждый момент времени каждый процесс работает в каком-либо одном домене защиты. Другими словами, имеется некоторая коллекция объектов, к которым он может получить доступ, и для каждого объекта у него есть определенный набор разрешений. Во время выполнения процессы имеют право переключаться с одного домена на другой домен. Правила переключения между доменами в большой степени зависят от системы.
Чтобы идея домена защиты выглядела более конкретно, рассмотрим пример из системы UNIX. В UNIX домен процесса определяется его идентификаторами UID и GID процесса. По заданной комбинации (UID, GID) можно составить полный список всех объектов (файлов, включая устройства ввода/вывода, представленные в виде специальных файлов и═т.═д.), к которым процесс может получить доступ с указанием типа доступа (чтение, запись, исполнение). Два процесса с одной и той же комбинацией (UID, GID) будут иметь абсолютно одинаковый доступ к одинаковому набору объектов.
Более того, каждый процесс в UNIX состоит из двух частей: пользовательской части и системной части. Когда процесс обращается к системному вызову, он переключается из пользовательской части в системную. Пользовательская и системная части процесса имеют различный доступ к различным множествам объектов. Например, системная часть процесса может иметь доступ ко всем страницам в физической памяти, ко всему диску и ко всем другим защищенным ресурсам. Таким образом, системный вызов осуществляет переключение доменов защиты.
Когда процесс выполняет системный вызов exec с файлом, у которого установлен бит SETUID или SETGID, процесс может получить новые идентификаторы UID и GID. При новой комбинации UID и GID процесс получает новый набор доступных файлов и операций. Запуск программы с установленным битом SETUID или SETGID также представляет собой переключение домена, так как права доступа при этом изменяются.
Важным вопросом является то, как система отслеживает, какой объект какому домену принадлежит. Можно себе представить большую матрицу, в которой рядами являются домены, а колонками═≈ объекты. На пересечении располагаются ячейки, содержащие права доступа для данного домена к данному объекту (рис.═2). При наличии подобной матрицы операционная система может для каждого домена определить разрешения к любому заданному объекту.
Рис.═2.═Матрица защиты
Переключение между доменами также может быть легко реализовано при помощи все той же матрицы, если считать домены объектами, над которыми возможна операция enter (вход). На рисунке═3 снова изображена та же матрица, что и на предыдущем рисунке, но с тремя доменами, выступающими и в роли объектов. Процессы могут переключаться с домена═1 на домен═2, но обратно вернуться уже не могут. Эта ситуация моделирует выполнение программы с установленным битом SETUID в UNIX. Другие переключения доменов в данном примере не разрешены.
Рис.═3.═Матрица защиты с доменами в роли объектов
На практике, однако, разрешения доступа редко хранятся в виде матрицы, показанной на рис.═3, поскольку такая матрица была бы очень большой и практически пустой. Поэтому, как правило, такие матрицы хранятся по рядам или столбцам, причем хранятся только непустые элементы. Эти два подхода, как ни странно, различаются между собой. В данном разделе мы рассмотрим хранение матрицы защиты по столбцам, в следующем разделе мы познакомимся с методом ее хранения по рядам.
В первом методе с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки, называемые ACL-списками (Access Control List═≈ список управления доступом), проиллюстрированы на рис.═4. Здесь мы видим три процесса, принадлежащих различным доменам A, B и C, а также три файла, F1, F2 и F3. Для простоты мы будем предполагать, что каждому домену соответствует один пользователь, в данном случае A, B и C.═Часто в литературе по информационной безопасности пользователей называют субъектами или принципалами (владельцами объектов), чтобы отличать их от объектов, которыми кто-то владеет.
Рис.═4.═Использование ACL-списков для управления
доступом к файлам
С каждым файлом связан ACL-список. У файла F1 в его ACL-списке есть три записи (разделенные символом точка с запятой). В первой записи утверждается, что любой процесс, которым владеет пользователь═A, может читать и писать этот файл. Во второй записи говорится, что любой процесс, которым владеет пользователь═B, может читать этот файл. Все остальные типы доступа для данных пользователей запрещаются. Всем остальным пользователям запрещен любой доступ к этому файлу. Обратите внимание, что права предоставляются не процессу, а пользователю. Таким образом, любой процесс, которым владеет пользователь═A, может читать и писать файл═F1. Не имеет значения, один такой процесс или их 100. Значение имеет идентификатор владельца, а не процесса.
У файла═F2 в его ACL-списке есть три записи: пользователи═A, B и C могут читать файл, а пользователь═B также может писать в него. Другие типы доступа не разрешаются. Файл═F3, по-видимому, представляет собой исполняемую программу, так как пользователи A и B могут как читать, так и исполнять его. Пользователю═B также разрешается писать в этот файл.
Этот пример иллюстрирует самую общую форму защиты при помощи ACL-списков. Часто на практике используются более сложные системы. Начнем с того, что мы здесь показали только три типа доступа: чтение, запись и исполнение. Кроме них может быть еще много других типов доступа. Некоторые типы доступа могут быть применимы ко всем объектам, например уничтожение или копирование объекта, а некоторые могут быть специфическими для определенных объектов. Примеры подобных разрешений: добавить сообщение для объекта почтовый ящик и сортировать в алфавитном порядке для объекта каталог.
До сих пор мы рассматривали ACL-списки индивидуальных пользователей. Многими системами поддерживается концепция групп пользователей. У групп есть имена, и они также могут включаться в ACL-списки. Возможно применение двух вариантов семантики групп. В некоторых системах у каждого процесса есть идентификатор пользователя UID и идентификатор группы GID. В═других системах ACL-списки содержат записи вида:
UID1, GID1: права1; UID2, GID2: права2;┘
При такой схеме, когда к объекту поступает запрос доступа, выполняется проверка с помощью UID и GID обращающегося с запросом процесса. Если они присутствуют в ACL-списке, то перечисленные в списке права предоставляются процессу. Если комбинации (UID, GID) нет в списке, в доступе к объекту отказывается.
Продолжение следует
КОМПЬЮТЕР-ИНФОРМ Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
e-mail:
Для пресс-релизов и новостей