
- •Теоретические основы компьютерной безопасности
- •Содержание
- •Федеральный закон об электронной подписи n 63-фз от 6 апреля 2011 года 81 список сокращений
- •Основные определения
- •Информация
- •Федеральный закон российской федерации от 27 июля 2006 г. №149-фз «об информации, информационных технологиях и о защите информации»
- •Парольные системы для защиты от нсд к информации
- •Общие подходы к построению парольных систем
- •Выбор паролей
- •Организация иб
- •Анализ угроз иб
- •Построение систем защиты от угрозы нсд
- •Защита на уровне представления или криптографические методы защиты информации
- •Концепция ас
- •Сопряжение симметричной и ассиметричной системы
- •Схемы рассылки ключей диффи - хэлмана
- •Протоколы
- •Схемы применимости скзи
- •Эцп от 10 января 2002 года n 1-фз
- •Инфраструктура открытых ключей
- •Стенография
- •Принципы обеспечения целостности
- •Модель контроля целостности биба
- •Модификация модели биба
- •Теория модели безопасности, монитор безопасности
- •Проблема безопасностей моделей
- •Защита памяти
- •Предотвращение неисправностей по в ас, построение сз от угроз отказа доступа, защита от сбоев па среды
- •Дискреционная модель управления доступом
- •Модель хру
- •Дискреционная модель управления доступом
- •Ролевое управление доступом
- •Оранжевая книга – требования tcb
- •Дерево ролей
- •Модель доменов и типов
- •Информационные модели безопасности
- •Модель распространения прав доступа take-grant
- •Расширенная модель take - grant
- •Федеральный закон об электронной подписи n 63-фз от 6 апреля 2011 года
Ролевое управление доступом
Является эволюцией дискреционных моделей.
Содержат признаки мандатной модели.
Субъект является обезличиным внутри роли.
Содержит матрицу доступа «Роли/Объекты», а не «Субъекты/Объекты».
Содержит дополнительную информацию о принадлежности субъектов к ролям.
Пример ролевой модели: доменная система windows NT.
Windows не является ролевой, как и дискреционной. В Access Control List могут содержаться идентификаторы (Security Identifier) как на группы, так и на пользователей, получается смесь, а также существует группировка объектов ( типы) аналог роли, но для объектов.
Система Windows является коммунистической, т.е. запрещено все, кроме того, что явно разрешено. Но в Access Control List могут содержаться как разрешения, так и запреты. В Master File Table содержатся дескрипторы безопасности, которые также присоединяются к объектам. В Access Control List хранятся только назначения или запрещенные права.
Согласование ролей – коммунистическое.
В Windows на уровне NTFS приоритетом обладает запрет.
Привилегии - субъект присутствует, но объект отсутствует. Пример: привилегия – отладка; привилегия – архивация; привилегия – создание (права).
Явно привилегии появляются в ролевой модели.
Оранжевая книга – требования tcb
TCB можно доверять
Система безопасности регулируется в TCB
Остальное вне 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/... можно подменить библиотеку – меняется система аутентификации программы.