Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции ТОКБ.doc
Скачиваний:
135
Добавлен:
17.03.2015
Размер:
445.95 Кб
Скачать

Ролевое управление доступом

  1. Является эволюцией дискреционных моделей.

  2. Содержат признаки мандатной модели.

Субъект является обезличиным внутри роли.

  1. Содержит матрицу доступа «Роли/Объекты», а не «Субъекты/Объекты».

  2. Содержит дополнительную информацию о принадлежности субъектов к ролям.

Пример ролевой модели: доменная система windows NT.

Windows не является ролевой, как и дискреционной. В Access Control List могут содержаться идентификаторы (Security Identifier) как на группы, так и на пользователей, получается смесь, а также существует группировка объектов ( типы) аналог роли, но для объектов.

Система Windows является коммунистической, т.е. запрещено все, кроме того, что явно разрешено. Но в Access Control List могут содержаться как разрешения, так и запреты. В Master File Table содержатся дескрипторы безопасности, которые также присоединяются к объектам. В Access Control List хранятся только назначения или запрещенные права.

Согласование ролей – коммунистическое.

В Windows на уровне NTFS приоритетом обладает запрет.

Привилегии - субъект присутствует, но объект отсутствует. Пример: привилегия – отладка; привилегия – архивация; привилегия – создание (права).

Явно привилегии появляются в ролевой модели.

Оранжевая книга – требования tcb

  1. TCB можно доверять

  2. Система безопасности регулируется в TCB

  3. Остальное вне TCB регулируется системой безопасности.

Дерево ролей

Существуют информационные системы, в которых роли строятся по принципу вложенности, т.е. выбираются примитивы.

Доказана теорема о изоморфизме дерева ролей и решетке Белла - Лападула.

Под операцией понимается получение доступа, следовательно, модель Белла - Лападула может быть реализована на ролевой модели.

Ролевая модель недоказуема.

Модель доменов и типов

Первоначально появилась для UNIX – систем.

Домен (роль) – это группа, в смысле группировки пользователей.

Типы – типы для объектов.

Строится две матрица:

Домен(роль)/тип

домен/домен – может ли один субъект другого убить/породить, то какими правами обладает субъект по отношению к другому субъекту.

Можно обойтись одной матрицей, берем первую. В добавляем функции.

Монитор безопасности (Редактор матрицы)

Изначально в *NIX системах были флаги SETUID, SETGID. В LINUX существует два файла:

/etc/passwd – информация о пользователях: логин, пароль(изначально он был там, без хэш-а), описание пользователя(расшифрование admin, гость), принадлежность к группе(admin,гость), корневая папка, оболочка (то, что запустится, когда войдет пользователь).

В последствии пароли были убраны с passwd в shadow и были доступны только админу (хэш-свертки.

Pwd.h –файл для работы с функциями. getpwnam – возвращает все информацию о пользователе без хэш-а и пароля. Доступна от имени любого пользователя.

В LINUX программа может менять свой идентификатор – это регулируется setuid, setguid.

Пример: программа su – позволяет получить права администратора, позволит дальше в данном терминале запускать все от admin. Работа: флаг взведен – она может переходить в режим admin - у пользователя только права на запуск программы. Далее уже имеет права admin, далее обращается в shadow и может перевести пользователя в режим admin.

/etc/shadow

Функции для работы с shadow: shadow.h – include

Man shadow.h – чтобы узнать что делает shadow.

PAM – pluggable authentication modules – набор унифицированных модулей для процессов аутентификации, связаны с shadow.

Рисунок 18 - Механизм работы

Все функции начинаются со слов pam.

Pam_auth

Pam_start – инициализация системы, ей передается (имя программы, имя пользователя от которого запускается pam, функция (структура содержащая адрес функции*), handle сеанса pam).

Эти функции можно запускать имея права root.

*-функции сеанса ввода данных – принимает набор указателей переменных от pam – сообщения и внутри функции можно определить как эти переменные будут использоваться.

Pam_authenticate – принимает два аргумента (handle, число, которое оно вернет если аутентификация пройдет неудачно).

Для каждой программы использующей PAM должен быть файл(/etc/pam.d/) в нем есть цепочка аутентификации – указываются имена библиотек auth_required_pam_unix.iso, pam_rootok.iso (выдает аутентификации прошла хорошо, если от имени root (заглушка)).

Атаки:

Модуль PAM можно самим написать – подмена модуля.

В файле /etc/pam.d/... можно подменить библиотеку – меняется система аутентификации программы.