Выполнение работы

1. Получить доступ к набору служебных программ «Монитор безопасности»:

• expert.exe (программа преобразования файла описания модели в ехе-файл);

• security.exe (основная программа «Монитора безопасности»).

2. Создать файл описания модели, основанной на типизированной матрице доступа, при помощи языка описания. Исходные данные задаются препода­вателем. Особенности языка описания модели приведены в Приложении 2.

3. Используя программу expert.exe, получить ехе-файл. Последовательность работы с утилитой expert.exe определена в Приложении 3.

4. Запустить программу security.exe. Описание ее возможностей приведено в Приложении 4.

5. Выбрать в меню FILE созданный ехе- файл.

6. Убедиться в защищенности информации в системе с реализованной ТАМ. Для этого необходимо для нескольких пар «субъект-объект» выполнить раз­решенные и запрещенные операции и удостовериться в возможности осу­ществления и предотвращения вторых.

7. Выйти из программы security.exe, если субъектам запрещено выполнение операции create subject.

8. Реализовать одну из проблем ТАМ, определенную при рассмотрении поли­тики контролируемого источника - а именно, возможность косвенного полу­чения доступа к конфиденциальной информации. Для этого необходимо:

   • разрешить выполнение операции create subject одному из субъектов и повторить выполнение пунктов 3 - 5, если эта операция не была раз­решена ранее;

   • в рамках предложенной модели необходимо создать дочерний субъ­ект, который имеет доступ к секретному объекту, т.е. имеет большие полномочия.

9. Привести результаты, подтверждающие возможность обхода защиты, пре­доставляемой ТАМ. Для этого необходимо выполнить доступ, который по­зволен типом созданного дочернего субъекта.

10. Выйти из программы security.exe.

11. Доопределить файл описания модели таким образом, чтобы создание до­чернего субъекта или копии секретного документа было возможно только с разрешения владельца документа.

12. Повторить выполнение пунктов 3-5.

13. Убедиться в предоставляемой защите ТАМ. Для этого необходимо проде­лать действия пункта 6.

14. Покинуть программу security.exe.

Содержание отчета

В отчете необходимо привести:

1. Исходные данные:

• набор субъектов и объектов, а также соответствующие атрибуты;

• файл описания модели с ТАМ;

• содержимое prefile и postfile, если таковые используются.

2. Результаты, подтверждающие защищенность информации при реализации модели ТАМ.

3. Результаты, подтверждающие возможность обхода защиты, обеспечиваемой ТАМ.

4. Решение проблемы политики контролируемого источника и подтверждающие это результаты.

5. Выводы по лабораторной работе.

Пример отчета

1. Исходные данные:

Рассмотрим простейший пример из политики контролируемого источника.

Пусть в системе присутствует субъект типа «user» и субъект типа «patron». Пусть в системе существует документ - объект типа «secret», вла­дельцем которого является субъект типа «patron». Субъекту типа «patron» раз­решены любые операции над документом и над субъектом типа «user». Субъ­екту типа «user» изначально разрешено все, кроме чтения и записи в секрет­ный документ. Файл описания модели выглядит следующим образом:

//tam.ini

S(1, 1,0,0,0,0,0,0,0); //"user"-type

S(2, 0,1,0,0,0,0,0,0); //"patron"-type

О(1, 1,0,0,0,0,0,0,0); //"secret"-type

ATTRNAME user IS ATTRS(1);

ATTRNAME patron IS ATTRS(2);

ATTRNAME secret IS ATTRO(1);

RULES

READO IF(patron[THISS])

READS IF(patron[THISS])

WRITEO IF(patron[THISS])

WRITES IF(patron[THISS])

EXECUTED IF(patron[THISS])

EXECUTES IF(patron[THISS])

CREATED IF(patron[THISS] || user[THISS])

CREATES IF(patron[THISS] || user[THISS])

DELETED IF(patron[THISS] || user[THISS] &&THISO!=1)

DELETES IF(patron[THISS] || user[THISS] &&THISS!=2)

CHOATTR IF(patron[THISS] || user[THISS] &&THISO!=1)

CHSATTR IF(patron[THISS] || user[THISS] && THISS!=1)

ENDRULES

Prefile и postfile не использовались.

2. Модель ТАМ, как показывает ее тестирование, обеспечивает надежную за­щиту информации.

3. Ограничения действий субъекта типа «user» касаются только секретного до­кумента. Но при тестировании такой модели сразу же обнаруживается недоста­ток ТАМ: субъект типа «user» может создавать дочерние субъекты и объекты, а также наделять их любыми правами (в итоге, субъект-потомок, имея тип «user», получит более мощные права, чем имел родитель, и сможет действовать в ин­тересах предка - это вторая проблема модели ТАМ. Ее анализ и решение воз­можны в качестве дополнительного задания к данной лабораторной работе).

В этом случае, субъект имеет право создать субъект того же типа и объ­ект-копию с необходимыми атрибутами и, после того как субъект типа «patron» разрешит субъекту типа «user» чтение документа, дочерний субъект получит доступ к копии. Произойдет утечка информации.

4. Для устранения данного недостатка необходим контроль со стороны субъек­та типа «patron» действий (в частности, операций создания и изменения атри­бутов дочерних сущностей) субъектов более ограниченных по возможностям типов. Одно из решений проблемы - запрещение создания и смены атрибутов дочерних сущностей субъекта типа «user» с сохранением права чтения доку­мента, что реализуется в файле описания.

Контрольные вопросы по лабораторной работе

1. В чем заключается особенность модели, основанной на типизированной матрице доступа?

2. Каким образом происходит распределение прав в модели с ТАМ?

3. Каковы основные недостатки модели, основанной на применении ТАМ?

4. В чем состоит проблема политики контролируемого источника?

5. Каковы способы решения проблемы политики контролируемого источника?

Лабораторная работа № 5

Модель доменов и типов для UNIX-систем

Цель работы: исследовать возможности, представляемые моделью доменов и ти­пов.

Средства: методика проведения лабораторной работы, теоретический материал, персональный компьютер.

Время: 4 часа.

Теоретические сведения

Навязывание доменов и типов

Поскольку системы на основе ОС UNIX стали основной частью всемир­ной информационной инфраструктуры, механизмы безопасности этой ОС на­ходятся под постоянным вниманием критиков.

В настоящее время управление доступом в ОС UNIX реализуется с по­мощью битов защиты и специального механизма setuid/setgid, что возлагает большую ответственность на привилегированные программы и администрато­ра. Это приводит к следующим последствиям:

• системы UNIX зачастую представляют собой "самое слабое звено", в котором при компрометации любой привилегированной программы (например, fingerd, lpd, rdist) уязвимой становится вся система.

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

ОС UNIX теоретически можно сделать устойчивыми к угрозам, дополнив их уровнем управления доступом, который ограничивал бы действия привиле­гированных процессов с целью минимизации возможного ущерба от компроме­тации или ошибки. Однако это не было реализовано в большинстве систем UNIX, даже несмотря на то, что давно уже имелся целый ряд механизмов управления доступом. Одной из причин послужило то, что усовершенствования в системе защиты зачастую требуют значительных затрат, вызываемых более сложным администрированием системы, несовместимостью приложений и до­полнительным обучением пользователей.

В настоящей работе рассмотрим новую форму управления доступом -модель с реализованной политикой навязывания доменов и типов (DTE - Do­main and Type Enforcement), или модель доменов и типов для системы UNIX. Политика безопасности DTE была специально сформулирована так, чтобы от­вечать наиболее важным требованиям как поставщиков, так и пользователей, а именно, в ней учитывается гибкость, простота и возможность взаимодействия с операционной системой, совместимость и производительность.

DTE представляет собой комбинированный вариант навязывания ролей, типов и табличного механизма управления доступом. Как и большинство схем управления доступом, при навязывании типов система рассматривается как совокупность активных элементов (субъектов) и пассивных элементов (объек­тов). В навязывании типов для UNIX с каждым субъектом (процессом) связан атрибут управления доступом - домен, а с каждым объектом (файлом, сообще­нием, сегментом общей памяти и т.д.) связан другой атрибут - тип. В глобаль­ной таблице определения доменов представлены допустимые режимы досту­па между доменами и типами (например, чтение, запись, выполнение), а в таблице взаимодействия доменов, представлены допустимые режимы досту­па между доменами (например, освобождение, создание, уничтожение). По ме­ре работы системы попытки доступа фильтруются с помощью этих таблиц: а именно, не разрешается доступ в режимах, не авторизованных в этих табли­цах.

Недостатки политики DTE

Отметим следующие недостатки, возникающие при реализации навязы­вания доменов и типов:

• несмотря на то, что навязывание типов является очень гибким, табли­цы управления доступом могут быстро стать слишком сложными, по­этому навязывание типов трудно реализовать на практике;

• кроме того, из-за наличия атрибутов типа у файлов требуется новый несовместимый со старым формат файловой системы.

Для разрешения этих проблем DTE улучшает навязывание типов с двух сторон:

1. Политики DTE определяются на языке DTE (DTEL-DTE language) -языке высокого уровня, с помощью которого могут быть выражены многократно используемые конфигурации управления доступом, совместимые с современ­ными приложениями и конфигурациями систем.

2. При работе системы атрибуты безопасности файлов DTE не хранятся в явном виде как файлы на диске, а сохраняются неявно в виде иерархии ката­логов и, таким образом, компактно представляют части иерархии файлов, имеющих идентичные атрибуты. Следовательно, благодаря неявной организа­ции типов DTE можно применять к существующим файлам, не изменяя фор­мат файловой системы.

DTE представляет собой гибкий механизм управления доступом на уров­не ядра При каждой системной загрузке система UNIX с DTE обрабатывает спецификацию DTEL и устанавливает управление доступом во время инициа­лизации ядра UNIX. Все процессы, в том числе и корневые, подвергаются кон­тролю со стороны DTE.

В данной лабораторной работе мы исследуем неполный вариант модели безопасности, а точнее - ее прототип, реализующий навязывание домена и ти­па посредством глобальной таблицы определения доменов (доступ между до­менами и типами) и таблицы взаимодействия доменов (доступ между домена­ми), т.е. без введения языка DTE. В таком случае политика DTE - обобщение RBAC (если ассоциировать понятие «домен» с понятием «роль») и ТАМ. Соот­ветственно, в этом случае проблемы политики DTE будут аккумулировать не­достатки RBAC и ТАМ.