Операционные системы. Управление ресурсами
Объектно-ориентированная модель доступа и механизмы защиты
В главе 7 мы рассмотрели модель управления доступом применительно к файловой системе. Управление доступом к файлам является частным случаем более общей модели управления доступом субъектов к объектам. Другой частный случай мы рассмотрели в главе 3 применительно к памяти. Модель рассматривает объекты - элементы системы, которым требуется защита, и субъекты - активные элементы, стремящиеся получить доступ к объектам. Типичный пример объекта - файл, типичный пример субъекта - процесс. Элемент, выступающий в одной ситуации, в роли субъекта, в другой ситуации может выступать в роли объекта. Так, например, необходимо обеспечивать защиту адресных пространств одних процессов (объектов) от других процессов (субъектов).
Механизмы защиты должны обеспечивать ограничение доступа субъектов к объектам: во-первых, доступ к объекту должен быть разрешен только для определенных субъектов, во-вторых, даже имеющему доступ субъекту должно быть разрешено выполнение только определенного набора операций.
Для обеспечения защиты могут применяться следующие механизмы:
- кодирование объектов;
- сокрытие местоположения объектов;
- инкапсуляция объектов.
Кодирование предполагает шифрование информации, составляющей объект. Любой субъект может получить доступ к информации, но воспользоваться ею может лишь привилегированный субъект, знающий ключ к коду. Другой вариант защиты через кодирование предполагает, что расшифровка информации производится системными средствами, но только для привилегированных субъектов. Кодирование не защищает объект от порчи, поэтому оно может использоваться только для защиты узкого класса специфических объектов или в качестве дополнительного средства в сочетании с другими механизмами защиты. Рассмотрение способов кодирования не входит в задачи нашего пособия, оно должно происходить при изучении курса "Защита информации".
Сокрытие местоположения объекта предполагает, что адрес объекта в памяти системы известен только тем субъектам, которые имеют право доступа к объекту.
Такие привилегированные субъекты могут выполнять любые операции над объектом. Непривилегированные субъекты могут запрашивать доступ к объекту и получать некий внутренний идентификатор объекта. Используя этот идентификатор, они могут выполнять над объектом ограниченный набор операций, но не непосредственно, а обращаясь к привилегированным субъектам. Примером такого механизма является сокрытие дескрипторов ресурсов. Местоположение (адрес в памяти) дескрипторов известно ОС, прикладные же процессы получают манипулятор ресурса, который, как правило, адресует дескриптор только косвенно (через таблицы). Если сокрытие является единственным механизмом защиты, то защиту нельзя назвать непроницаемой. Субъект может получить адрес объекта случайно или намеренно (получив доступ к внутренней документации).
Инкапсуляция предполагает полное закрытие для субъектов возможности оперирования с внутренним содержимым объектов. Субъект даже не должен знать структуры этого содержимого. Для каждого объекта, однако, определено множество допустимых операций над ним, которые реализуются монитором объекта. Объект, таким образом, предстает в виде "черного ящика" с четко специфицированными входами и выходами и с абсолютно непроницаемыми стенками. Механизм инкапсуляции может обеспечивать наиболее полную защиту, но его реализация требует решения двух важных вопросов: во-первых, как обеспечить "непрозрачность стенок", во-вторых, как принимать решения о предоставлении доступа или об отказе в нем.
Непроницаемость ящика обеспечивается чаще всего средствами защиты памяти. Область памяти, в которой расположен объект, делается недоступной для любых субъектов, кроме монитора, реализующего операции над объектом. Как мы знаем (см. главу 3), защита памяти поддерживается аппаратными средствами вычислительных систем, и защита объектов, таким образом, представляется реализованной на аппаратном уровне. Надежность такой защиты, однако, в значительной степени иллюзорна. Во-первых, память также представляет собой объект, нуждающийся в защите.
От того, насколько сама защита памяти защищена от перепрограммирования ее произвольным субъектом, зависит эффективность всей системы защиты в целом. Во-вторых, аппаратно поддерживается только конечное число уровней защиты памяти, на практике же используются только два уровня: доступ к ограниченному подмножеству адресов и полный доступ. Если в системе имеется большое количество объектов разного типа, то каждый тип обеспечивается своим монитором. Если все мониторы работают с полным доступом, то нет гарантии в том, что монитор в результате, например, ошибки в нем не воздействует на объект, не предусмотренный в данной операции.
Наиболее надежным образом защита памяти достигается при помощи изоляции адресных пространств процессов и мониторов. Если таблицы дескрипторов ресурсов и сами ресурсы располагаются в отдельных адресных пространствах, то процесс просто не может получить к ним доступа, а может воздействовать на них только косвенно, передавая в системном вызове индекс элемента в недоступной для него таблице. Адресные пространства различных мониторов тоже могут быть изолированы друг от друга, что (при надежной изоляции) исключит воздействие ошибки в мониторе на другие ресурсы.
Для каждого объекта определено множество допустимых для него операций. Применительно к файлам, например, возможны в общем случае следующие операции:
- Read - получение информации из объекта;
- Write - обновление информации в объекте;
- Append - добавление в объект новой информации (не изменяя старой);
- Execute - интерпретация объекта как исполняемого кода;
- Delete - уничтожение объекта;
- Getinfo - получение информации об объекте;
- Setinfo - установка информации об объекте;
- Privilege - установка прав доступа к объекту (частный случай Setinfo, по понятным причинам выделенный в отдельную операцию).
Неизбыточный набор операций повышает надежность объекта, лишая потенциального "взломщика" возможностей воздействовать на объект. Так, например, для объекта "программа" могут отсутствовать операции Read и Write.
Действие всех компьютерных вирусов заключаются в том, что они читают программный файл, как файл данных, и дописывают в него (как в файл данных) коды, выполняющие несанкционированные действия. Если программу невозможно читать и писать, то у вируса просто нет возможности "заразить" ее своим кодом.
Перечень всех операций, допустимых для данной пары субъект-объект, составляет привилегию доступа (access privilege) или право доступа (access right) данного субъекта к данному объекту.
Каждая пара субъект-объект при каждом акте доступа взаимодействует в определенном режиме доступа (access mode). Условием разрешения доступа является совпадение запрошенного субъектом режима доступа с его привилегиями по отношению к запрошенному объекту.
Проведение политики контроля доступа включает в себя процедуры аутентификации и авторизации, показанные на рис.10.1.
 Рис.10.1. Процедуры аутентификации и авторизации |
Помимо имен и паролей, в профиль также могут входить настройки интерфейса рабочего места, процедура, автоматически выполняемая при начале пользователем сеанса, установки библиотек и каталогов для поиска и т.д.
и т.п. В профиль может также входить "бюджетная информация" (account) - сведения о правах доступа и полномочиях пользователя. Даже в системах защиты, ориентированных на списки контроля доступа, некоторые данные бюджета все равно содержатся в профиле пользователя: его имя и пароль, его полномочия, список групп, к которым он принадлежит. (Некоторые из составляющих бюджета объясняются ниже.) Профили пользователей должны быть одними из наиболее строго защищаемых объектов в системе.
При входе пользователя в систему или при запуске приложения от его имени выполняется аутентификации (authentification). Эта процедура состоит в представлении пользователя системе при установлении связи с ней и подтверждении его подлинности. Подтверждение подлинности выполняется паролем. При выполнении аутентификации процесс входа в систему находит имя пользователя в базе профилей и сверяет введенный пользователем пароль с паролем, хранящимся в профиле. Как правило, пароль хранится в профиле пользователя в закодированном виде, причем используется кодирование на основе хеширования, не допускающее восстановление пароля по его хеш-коду. (Если пользователь забыл свой пароль, то даже системный администратор не может сообщить ему его пароль, а может только предоставить ему возможность назначить новый пароль.) Поэтому введенный пользователем пароль кодируется по тому же алгоритму и сравниваются уже хеш-коды паролей. При подтверждении системой легальности пользователя выбирается идентификатор безопасности для этого пользователя (косвенный указатель на бюджет пользователя), и этот идентификатор включается в контексты всех процессов, создаваемых данным пользователем. Естественно, что пользователь (или приложение), не прошедший процедуру аутентификации, к работе не допускается.
В системах обычно предусматривается возможность входа в систему пользователя-гостя (guest). Такой пользователь имеет доступ только к полностью открытым ресурсам и не имеет никаких полномочий.
После входа в систему пользователь (или работающее от его имени приложение) может запрашивать доступ к ресурсам.Каждый случай получения пользователем тех ресурсов, которые включены в число защищаемых, сопровождается процедурой авторизации (authorization), которая заключается в проверке того, может ли данный пользователь выполнять запрошенное действие над данным объектом. В процессе выполнения авторизации привлекается информация безопасности, связанная с объектом и информация безопасности, связанная с пользователем, и выносится решение о предоставлении или отклонении доступа. В объектно-ориентированных системах процедура авторизации может быть решена единообразно. Любая операция получения ресурса (getResource) должна сопровождаться единообразной проверкой полномочий и привилегий субъекта по отношению к данному объекту.
