Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

2915

.pdf
Скачиваний:
1
Добавлен:
15.11.2022
Размер:
2.59 Mб
Скачать

Собственность - Какой пользователь(ли) и группа(ы) удерживает контроль установок прав вершины (node) и родителя вершины.

Права доступа - Назначаемые или переназначаемые в битовом выражении установки, которые разрешают некоторый тип доступа к собственности. Права доступа к каталогам могут иметь отличающиеся значения от оных у файлов, содержащихся в них.

Чтение:

-Возможность просмотра содержимого файла. -Возможность чтения каталога.

Запись:

-Возможность добавить или изменить файл. -Возможность удалять или перемещать файлы в каталоге.

Выполнение:

-Возможность запуска программы или скрипта оболочки

(shell script).

-Возможность поиска в каталоге, в комбинации с правом чтения.

Save Text Attribute: (Для каталогов).

sticky бит также имеет отличное значение применимо к каталогам. Если sticky бит установлен для каталога, то пользователь может удалять только те файлы, владельцем которых он является, или к которым ему явно заданы права записи, несмотря на то, что ему разрешена запись в этот каталог. Это сделано для каталогов подобных /tmp, в которые разрешена запись всем, но в которых нежелательно разрешать любому пользователю удалять файлы от нечего делать. sticky бит видно как 't' в полном режиме отображения содержимого каталога. (long listing).

SUID Attribute: (Для файлов)

Описывает set-user-id права на файл. Если права доступа set-user-id установлены во "владелец" и файл исполняемый, то процесс, который запускает его, получает доступ к системным ресурсам основываясь на правах пользователя, который создал этот процесс. Во многих случаях это является причиной

217

возникновения 'buffer overflow'.

SGID Attribute: (Для файлов)

Если установлен в правах доступа "группы", этот бит контролирует "set group id" статус файла. При этом он работает также как и SUID, только задействована при этом группа, а не отдельный пользователь.

SGID Attribute: (Для каталогов)

Если вы установите SGID бит для каталога (командой "chmod g+s directory"), то файлы, содержащиеся в этом каталоге будут иметь установки группы такие, как у каталога.

Вы - Владелец файла Группа - Группа, к которой вы принадлежите

Остальные - Любой в системе, кто не является владельцем либо членом группы.

Пример файла:

 

 

-rw-r--r-- 1 kevin users

114 Aug 28 1997 .zlogin

1й бит - каталог?

 

(нет)

2й бит - чтение владельцем?

(да, для kevin)

3й бит - запись владельцем?

(да, для kevin)

4й бит - выполнение владельцем? (нет)

5й бит - чтение группой?

 

(да, для users)

6й бит - запись группой?

 

(нет)

7й бит - выполнение группой?

(нет)

8й бит - чтение остальными?

(да, для остальных)

9й бит - запись остальными?

(нет)

10й бит - выполнение остальными? (нет)

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

-r--------

Разрешают чтение файла владельцем.

--w-------

Разрешают владельцу изменение или удаление

файла.

 

---x------

Владелец может выполнять эту программу, но

не скрипты

командного интерпретатора, которые еще

 

218

нуждаются в правах на чтение.

 

 

---s------

Будет

выполняться

с

эффективным

пользовательским ID = владелец.

 

 

-------s--

Будет

выполняться

с

эффективным

пользовательским ID = группа.

 

 

-rw------T

Не

обновлять "последнего времени

изменения". Обычно используется для swap файлов.

---t------ Не действует (прежде sticky бит).

 

Пример каталога:

 

 

 

drwxr-xr-x 3 kevin users

512 Sep 19 13:47

.public_html/

 

 

 

 

1й бит - каталог (да, содержит много файлов) 2й бит - чтение владельцем (да, для kevin)

3й бит - запись владельцем

(да, для kevin)

4й бит - выполнение владельцем (да, для kevin)

5й бит - чтение группой

(да, для users)

6й бит - запись группой

(нет)

7й бит - выполнение группой (да, для users)

8й бит - чтение остальными (да, для остальных) 9й бит - запись остальными (нет)

10й бит - выполнение остальными (да, для остальных) Следующие строчки являются примером минимальных установок прав, которые требуются для предоставления описанного доступа. Вы можете захотеть предоставить больше прав, чем приведено, но здесь описано, что эти минимальные

права на файл разрешают:

dr--------

Можно просмотреть содержание, но нельзя

прочесть атрибуты файла.

d--x------

Можно войти в каталог, а также использовать

его в полной записи файла (т.е. с путем к нему).

dr-x------

Владелец может теперь просмотреть атрибуты

файла.

 

d-wx------

Файлы теперь можно создавать/удалять, даже

если каталог

не текущий.

d------x-t

Предотвращает файлы от удаления остальными

 

219

с правами записи. Используется для /tmp. d---s--s-- Никаких действий.

Системные конфигурационные файлы (обычно в /etc) имеют обычно режим 640 (что означает -rw-r-----) и являются собственностью администратора. В зависимости от требований безопасности в вашей системе, вы можете изменить эти установки. Никогда не предоставляйте возможности записи в системные файлы для "группы" или "остальных". Некоторые конфигурационные файлы, включая /etc/shadow, должны разрешать чтение только администратору, а каталоги в /etc должны, по крайней мере, быть недоступны другим.

15. МЕТОДЫ И СРЕДСТВА ЗИ В СИСТЕМАХ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ (СУБД)

15.1. Модель подсистемы безопасности СУБД

Рассмотрим (в качестве рабочего примера) защищенную многопользовательскую СУБД ―ЛИНТЕР‖, разработанную НПП ―Релэкс‖ (г. Воронеж), сертифицированную Гостехкомиссией по 2 классу защищенности.

Модель защиты СУБД ЛИНТЕР обеспечивает полнофункциональную многоуровневую схему защиты данных на всех этапах обработки и хранения данных в системе. Она включает в себя принципы организации ЗИ, перечень блокируемых угроз, набор средств ЗИ, характеристику субъектов и объектов контроля.

Принципы организации ЗИ в СУБД ЛИНТЕР:

-СУБД ЛИНТЕР работает только с идентифицированными пользователями;

-все данные, хранящиеся в БД, имеют владельца и идентификационные метки;

-всем пользователям БД ставится в соответствие список прав доступа;

-пользователь может выполнить операцию только в

220

случае, если операция будет разрешена всеми уровнями защиты одновременно;

-администраторы не имеют непосредственно доступа к данным других пользователей. Их отличия от остальных заключаются только в возможности управлять другими пользователями;

-администратор безопасности не имеет непосредственно доступа к данным. Его функции заключаются в управлении ПСБ в целом и контроле работы пользователей на основе развитых средств разграничения доступа и регистрации событий;

-для многопользовательской сетевой работы может применяться принудительное управление доступом;

-пользователь может получить метки доступа запрашиваемых данных с целью дальнейшего контроля за дальнейшим использованием информации;

-все действия по каналам логической связи с БД надежно связаны с пользователем, который открыл данный канал. После закрытия логической связи невозможно пользоваться данным каналом;

-СУБД ЛИНТЕР использует принцип минимальных привилегий в случае, если привилегии не указываются явно.

Модель ПСБ противодействует следующим угрозам безопасности:

-действиям незарегистрированного пользователя; -действиям нарушителя от имени легального

пользователя; -получению данных без разрешения владельца;

-получению информации с высоким уровнем конфиденциальности пользователем с низким уровнем конфиденциальности;

-понижению уровня конфиденциальности данных; -извлечению информации из пространств памяти,

переданной под контроль операционной системы; -размещению данных на выделенных устройствах; -подключению пользователей со слабо защищенных

221

устройств сети;

 

 

 

-неконтролируемому

распространению

конфиденциальной информации после выдачи ее из БД;

-падению надежности системы при сбоях в работе

оборудования;

 

 

 

-присвоению пользователем себе новых прав;

 

-нарушениям целостности ПСБ;

 

 

-нарушениям,

возникающим

при

ошибках

администрирования БД.

Средства защиты информации в СУБД ЛИНТЕР: -диспетчер доступа; -средства аутентификации;

-многоуровневая система разграничения доступа; -подсистема дискреционного доступа; -подсистема мандатного доступа;

-средства контроля целостности информации; -средства аудита; -подсистема контроля доступа с внешних устройств; -подсистема очистки памяти;

-подсистема контроля за внешними физическими устройствами хранения информации.

Объекты контроля в СУБД ЛИНТЕР.

Объектами контроля (защиты) в СУБД ЛИНТЕР являются таблицы и представления, а также столбцы и строки таблиц (поля строк).

Таблицы базы данных и представления являются именованными объектами, имеющими владельца (создателя). Массивы данных, построенные на основе таблиц, содержат информацию в виде множества строк (записей) одинаковой структуры. Строки таблиц разбиты на поля именованными столбцами. Все поля соответствующие одному столбцу имеют один и тот же тип и длину данных.

Представление (View) представляет собой SQL-запрос - выборку из таблиц СУБД, образуемую при обращении к нему.

Все объекты защиты перечислены в табл. 12. 222

Таблица 12.

Объекты защиты в СУБД

Объект защиты

Логическая защита

Физическая защита

Базовая таблица

+

+

Представление

+

 

Столбец

 

+

таблицы

 

 

Строка таблицы

 

+

Поле

 

+

Логическая защита в ЛИНТЕР представляет собой набор прав субъектов или ролей по отношению к защищаемому объекту:

-владение таблицей (представлением); -возможность для владельца таблицы изменять набор

прав (расширять, отнимать, ограничивать доступ).

Данные о логической защите находятся в системных таблицах базы и отделены от защищаемых объектов (от таблиц или представлений).

Физическая защита в ЛИНТЕР реализована в виде меток безопасности и характеризует групповые принадлежности, уровни конфиденциальности и ценности объекта (таблицы, столбца, строки или поля). Метки безопасности неизменны на всем протяжении существования объекта защиты (умирают только вместе с ним) и территориально (на диске) располагаются вместе с защищаемыми данными.

Все объекты СУБД (независимо от их иерархии в базе данных) разбиваются на группы принадлежности. Объект может принадлежать только одной из групп (это может быть, например, разбиение по отделам организации).

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

223

отношения доверия.

Уровень конфиденциальности разбивает объекты по доступности с точки зрения возможности чтения (и видения). Пользователь с более низким уровнем доступа не будет знать даже о существовании объектов с более высоким уровнем конфиденциальности.

Уровень ценности, напротив, разбивает данные (объекты) по важности, ограничивая возможность их удаления и модификации.

Субъекты контроля в ПСБ СУБД ЛИНТЕР Все субъекты контроля СУБД разделены в соответствии

с дискреционным принципом контроля на три основные категории: Connect, Resource и Dba:

-Connect – категория, дающая право на присоединение пользователя к системе и подачу запросов к доступным ему данным;

-Resource – категория, имеющая все возможности Connect плюс возможности изменения структуры базы данных путем построения своих объектов контроля (таблиц, представлений);

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

В корпоративных базах данных, содержащих сотни (тысячи) субъектов и объектов, сложно определять права каждого субъекта при работе с каждым объектом. Поэтому, для упрощения этой процедуры в ЛИНТЕР реализован аппарат ролей.

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

224

пользователя роль (роли) можно отнять.

Мандатный принцип контроля, реализованный в СУБД ЛИНТЕР, предлагает:

-деление пользователей на группы доступа; -иерархию объектов по уровням доступа (десять уровней

с номерами от 1 до 10); -иерархию пользователей по уровням доверия (десять

уровней с номерами от 1 до 10).

Группа доступа субъекта указывает на его принадлежность к группе субъектов по доступу (это может быть, например, принадлежность к отделу организации, к группе людей, объединенных одними функциями и пр.). Группа назначается субъекту администратором безопасности, последний может так же переместить субъекта из одной группы в другую. Всего (в СУБД ЛИНТЕР) может быть 250 таких групп.

Группы доступа напрямую связаны с группами данных: -данным присваивается группа доступа (субъекта),

который их внес; -данные, принадлежащие одной группе, недоступны

пользователям другой группы; -одна группа может доверить другой группе работу со

своими данными.

Уровень доступа субъекта задается при его создании администратором безопасности или изменяется позже. Он определяет: какие из данных (по уровню конфиденциальности) доступны субъекту, а какие нет. Все данные с уровнем конфиденциальности более высоким, чем уровень доступа субъекта, последнему недоступны и он даже не подозревает об их существовании.

Уровень доверия субъекта (или уровень доверия субъекта на понижение уровня конфиденциальности) назначается администратором безопасности и определяет конфиденциальность данных, вводимых в БД их владельцем. ЛИНТЕР не позволит ему внести информацию с уровнем конфиденциальности ниже, чем уровень доверия субъекта.

225

Любая вносимая (изменяемая) этим субъектом информация уже будет иметь минимальный ―гриф‖ или уровень конфиденциальности.

15.2. СЗИ, используемые в ПСБ защищенной СУБД

Элементы архитектуры СУБД как СЗИ СУБД ЛИНТЕР - открытая система. По технологии

построения открытых систем, все ее алгоритмы открыты для всех пользователей и работают для всех одинаково. Прикладные пользовательские программы отделены от системы. Общение между ядром СУБД и приложением ее использующим проходит только через Call-интерфейс системы. Тексты/алгоритмы Call-интерфейса открыты, не содержат элементов СЗИ НСД. Алгоритм Call-интерфейса устроен таким образом, что раз установленная связь субъекта и СУБД идентифицируется еще идентификатором (каждая операционная система присваивает задаче уникальный идентификатор) прикладной задачи (см. п. Ошибка! Источник ссылки не найден.), что исключает возможность перехвата ответов от ядра ЛИНТЕР. Это означает, что ответ, посланный задаче на ее запрос, придет именно к этой задаче и ни к какой другой.

Все утилиты системы ЛИНТЕР написаны с использованием того же Call-интерфейса (т.е. штатных средств) и не используют никаких других, скрытых особенностей системы. Следуя технологии открытых систем, субъект контроля может обращаться посредством СУБД ЛИНТЕР к базе данных только из программ (поставляемых в дистрибутиве или подготовленных им самим) и только с помощью штатных средств системы.

ПСБ СУБД ЛИНТЕР реализована в виде части исполняемого кода ядра системы. Основа системы безопасности - диспетчер доступа получает управление на ранних этапах инициализации СУБД до запуска процедур

226

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]