Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
os8.doc
Скачиваний:
0
Добавлен:
20.06.2023
Размер:
264.7 Кб
Скачать
        1. Мандатный метод контроля доступа

Мандатный метод очень наглядно иллюстрируется терминами конфиденциальности.

Например, есть субъекты (пользователи), обладающие следующими уровнями доступа:

      • Низкий;

      • Средний;

      • Высокий.

То, что субъект обладает соответствующим уровнем доступа, означает, что ему присвоена соответствующая мандатная метка.

Объектам тоже назначаются соответствующие мандатные метки:

  • Низкий;

  • Средний;

  • Высокий.

Теперь в дело вступает политика мандатного управления доступом:

Политика в данном случае реализуется следующими правилами чтения и записи:

Рассмотренная модель разграничения доступа реализована, например, в ОС МСВС. Если кто-нибудь ее увидит, обратите внимание на кружок в правом нижнем углу. Этот кружок и показывает мандатный уровень доступа пользователя, вошедшего в систему. Уровней четыре, для их именования используют термины «не секретно», «секретно» и т. п.

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

3. Os api для управления безопасностью объектов

API операционных систем для управления безопасностью объектов рассмотрим на примере Windows.

В системных вызовах создания большинства объектов имеется следующий параметр:

LPSECURITY_ATTRIBUTES атрибут безопасности

который трактуется как указатель на атрибут безопасности.

Например, создание именованного канала:

HANDLE WINAPI CreateNamedPipe(

LPCTSTR имя,

DWORD режим открытия,

DWORD режим канала,

DWORD число экземпляров канала,

DWORD размер буфера передачи,

DWORD размер буфера приема,

DWORD тайм-аут,

LPSECURITY_ATTRIBUTES атрибут безопасности

);

Если последним параметром этой функции передать NULL, то обмен данными между сервером и клиентом, расположенными на разных машинах, производиться не будет.

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

Атрибут безопасности содержит три параметра, важнейшим из которых является указатель на дескриптор безопасности. Другими параметрами являются размер структуры и режим наследования дескриптора.

Дескриптор безопасности содержит права доступа к объекту.

Дескриптор безопасности содержит информацию о следующих компонентах безопасности объекта:

  • Идентификатор безопасности владельца

  • Идентификатор безопасности группы

  • Список контроля доступа (ACL)

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

Затем сам список может быть добавлен к ACL дескриптора.

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

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

Чтобы использовать дескриптор безопасности объекта, надо выделить под него память, а затем проинициализировать его.

Пример вызова представлен ниже:

PSECURITY_DESCRIPTOR pSD = LocalAlloc(…);

InitializeSecurityDescriptor(pSD);

Где PSECURITY_DESCRIPTOR pSD - указатель на дескриптор безопасности.

Затем необходимо найти идентификатор безопасности пользователя, который будет владеть объектом.

Это делается по имени пользователя следующим образом:

LookupAccountName(buffer,pSid);

Где buffer содержит имя пользователя;

pSid – это указатель на идентификатор безопасности;

Затем идентификатор безопасности привязывается к дескриптору безопасности. Это делается вызовом:

SetSecurityDescriptorOwner(pSD,pSid);

Затем создается список контроля доступа вызовом:

InitializeAcl(pAcl);

где pAcl - адрес списка контроля доступа

Затем в список контроля доступа вносятся элементы, либо позволяющие операции определенному пользователю (через его идентификатор, найденный функцией LookupAccountName), либо запрещающие какие-либо операции:

AddAccessAllowedAce(pAcl, AccessMask, pSid);

где AccessMask - маска доступа

BOOL AddAccessDeniedAce(pAcl, AccessMask, pSid);

На последнем этапе заполненный список заносится в дескриптор безопасности:

SetSecurityDescriptorDacl(pSD, pAcl);

Если указатель на список контроля доступа будет равен NULL, то будет использован список, позволяющий полный доступ к объекту:

Дескриптор безопасности вносится в атрибут безопасности, а указатель на атрибут безопасности передается в качестве параметра в функцию создания объекта.

SECURITY_ATTRIBUTES sa;

sa.nLength = sizeof(sa);

sa.lpSecurityDescriptor = pSD;

hPipe = CreateNamedPipe ( ...,&sa);

Интересно отметить, что отсутствие атрибута безопасности (NULL вместо &sa) и использование NULL-списка контроля доступа приводят к противоположным результатам.

В первом случае доступ полностью отсутствует, а во втором случае предоставляется полный доступ.

В UNIX-подобных ОС также реализованы списки контроля доступа.

Существуют команды ОС для чтения и формирования списков контроля доступа. Это команды:

getfacl и setfacl.

Кроме того, существуют функции для программирования списков контроля доступа. Это функции с префиксом acl.

Например:

acl_get_file(…) - получить список;

acl_get_entry(…) – получить элементы списка;

acl_get_permset(…) – получить права доступа в элементе списка;

acl_add_perm(…) – добавляет права доступа к элементу списка.

Помимо списков контроля доступа существует понятие «возможностей» - «capabilities». Здесь речь идет о POSIX-возможностях.

Это средство предоставления процессам отдельных прав суперпользователя.

Сочетание capabilities и acl используется при реализации мандатных методов контроля доступа.

Известны и поддерживаются следующие технологии мандатного контроля доступа:

  1. AppArmor;

  2. TOMOYO;

  3. Smack;

  4. SELinux.

Каждая из перечисленных технологий обладает своими достоинствами и недостатками. Общим в них является подход к реализации. А именно, использование механизма LSM – Linux Security Modules, который заключается в наличие средств перехвата системных вызовов.

Большинство системных вызовов к ресурсам (файлам, каталогам, устройствам) перехватываются функциями LSM. Исходно эти функции пустые, но имеют доступные для разработчиков адреса. Устанавливая на эти адреса свои функции, можно разрабатывать свои сколь угодно сложные методы контроля доступа к ресурсам.

Общая схема обращения к ресурсу представлена ниже.

15

Соседние файлы в предмете Операционные системы