Перевод описания модулей RSBAC

Rule Set Based Access Control (RSBAC) для Linux. Переводы документации, описаний и статьи по данной теме.

[ALT Linux Team]

Перевод: Александр Блохин  ]

Table of Contents
Модели RSBAC

Модели RSBAC

В настоящий момент в RSBAC входят следующие модели:

Mandatory Access Control (MAC)

Модель Белла и Ла-Падулы

Определения.

Модель Bell и La Padula описывает доступ активных объектов, называемых субъектами, к пассивным объектам, называемых объектами. Один объект, в зависимости от типа доступа, может представать в обеих ролях.

Различия между доступом на чтение и запись, могут различаться по четырем способам доступа: ни на чтение ни на запись (execute, e), только чтение (read, r), только запись (append, a) и чтение-запись (write, w). Набор всех типов доступа назван А.

Состояния Системы

Каждое обращение субъекта Si к объекту Oj способом x описывается таким набором как (Si,Oj,x). Вся эта троица вместе составляет набор текущих обращений b .

Объекты структурированы по принципу Отец-Сын и образуют иерархию H в одном, или более, независимых деревьях.

Все авторизованные обращения всех субъектов ко всем объектам содержатся в матрице M. Таким образом каждая ячейка Mij из M содержит поднабор из A с авторизованными обращениями от Si к Oj.

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

Один объект со степенью защиты (S1,C1) доминирует над другим объектом (S2,C2), если S1 >= S2 и C1 превосходит С2. Объект, доминирующий над всеми другими объектами, образует отношение доминирования D.

Назначение степени защиты для субъектов и объектов. Функция классификации F задается кортежем (fS,fO,fC) функций назначения степени защиты, где fS(Si) является максимальной степенью защиты для субъекта Si, fO(Oj) является степенью защиты объекта Oj и fC(Si) является текущей степенью защиты субъекта Si. Таким образом различаются максимальная и текущая степени защиты субъектов.

Для всех Si fS(Si) всегда должно доминировать над fC(Si).

Состояние модели z задается как набор из четырех элементов (b, M, F, H) таким образом система представляется в виде последовательности состояний с некоторым начальным состоянием z0.

Свойства Защиты

Первое используемое свойство это простое свойство защиты - не считываемость. Оно состоит в том, что субъект Si может иметь право доступа на чтение к объекту Oj ((Si,Oj,r) или (Si,Oj,w) это текущий доступ), если Si доминирует над Oj.

Схема 1: Незаконный информационный поток в модели Bell-La Padula.

Во избежание копирования злоумышленником объекта в уровень с меньшей степенью защиты добавляется еще одно свойство - “*-property” (не списываемость). Это свойство означает: если субъект Si имеет доступ на чтение к объекту O1 и доступ на запись к объекту O2, тогда O2 должно доминировать над O1 (O1 имеет более низкий уровень защиты, чем O2). Таким образом информационный поток ограничен свыше.

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

Контроль доступа матрицы М авторизованного доступа субъектов к объектам называется дискреционном контролем доступа, эта особенность защиты называется “ds-property”. Текущий доступ должен всегда быть в наборе авторизованного доступа в его матричной ячейке.

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

Правила Принятия Решений

Три свойства служат директивой для следующих правил управления доступом при принятии решения:

Текущий допуск (Si,Oj,x) предоставлен только в том случае, если выполнены следующие условия:

1. ss-property: Si доминирует над Oj, если x = r или x = w (x заключает в себе доступ на чтение).

2. *-property: Si является доверенным либо :

2.1. Oj доминирует над текущим уровнем Si, если режим = a

2.2. уровень Oj равен текущему уровню Si, если режим = w

2.3. текущий уровень Si доминирует над уровнем Oj, если режим = r

3. x-property: x находится в ячейке Mij авторизованных обращений матрицы M

Функции

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

Полный набор этих функций следующий:

  • Изменение набора b текущих допусков:

get-access(): добавить значение кортежа из трех элементов в набор b

release-access(): удалить значение кортежа из набора b

  • Изменение матрицы M авторизованных допусков:

give-access-permission(): добавить режим доступа в ячейку M

rescind-access-permission(): удалить режим доступа из ячейки M

  • Изменение классификационной функции F:

change-object-level()

change-current-level()

  • Изменение иерархии объекта H:

create-object(): создать листок объекта

delete-object-group(): удалить объект вместе с под-объектами из дерева

Определение

Модель Белла и Ла-Падулы касается только аспектов конфиденциальности. Целостность, пригодность и безопасность данных при этом не защищены. Например, субъект на самом низком уровне безопасности может удалять все данные во всех его категориях, если они предусмотрительно не защищены. Атаки подобные этой так-же могут случаться без пользовательской осведомленности, только подумайте о вирусах или ошибках. Управляемый контроль доступа особенно подвержен атакам троянцев.

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

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

Unix System V/MLS

Модель обязательного контроля доступа используемая в RSBAC в целом та-же самая, что и в Unix System V/MLS, версии 1.2.1. Эта операционная система была разработана в 1989 году Национальным Центром Компьютерной Безопасности США с классификацией B1/TCSEC.

Unix System V/MLS реализует модель Bell-La Padula с некоторыми небольшими изменениями, например ds-property заменена на контроль доступа в стиле UNIX. Уровни защиты снабжены категориями классификации, введены simple-security-property и *-property. В противоположность Bell-La Padula запись разрешена только на том же самом уровне.

Bell-La Padula определяет четыре модели доступа:

  • выполнение, E

  • чтение, R

  • запись, W

  • дополнение, A

Эта Unix-система добавляет еще 10 моделей, которые главным образом охватывают часть вышеупомянутых способов:

  • поиск в каталоге, S

  • перезапись, O

  • создание, C

  • связывание, L

  • разъединение (удаление), U

  • статус чтения файла/и-нода, St

  • статус изменения, Ch

  • послать сигнал/убить, K

  • читать IPC, Ripc

  • записать IPC, Wipc

Процессы являющиеся субъектами, наследующие свой собственный уровень защиты. Определены четыре типа объектов:

  • Файл

  • Каталог

  • Канал Межпроцессного Взаимодействия (IPC-Channel)

  • Данные Контроля Системы (SCD)

Состояния Запроса для доступа

R/S/E  S >= O
W(O/A) S = O
C/L/U  S = Od
St     S >= O
Ch     S = O
Ripc   S >= O
Wipc   S = O
K      S = O
    

Схема 2: Состояния Контроля Доступа в System V/MLS

Схема 2 показывает суммарные состояния контроля доступа. S означает субъект, O объект, Od объект каталога и >= и = стоит для обозначения доминирует и имеет тот-же уровень. Запись и чтение на каталогах подразумевает доступ к объектам без возможности их открытия.

Реализация RSBAC MAC

Модель Unix System V/MLS была изменена для соответствия схеме запроса доступа RSBAC, которой известно более 30 типов доступа. Также оригинальным способом реализована система дополнения так, что вы всегда можете осуществлять запись на все более высокие уровни. С версии 1.1.1 и выше запись разрешена только на тот же самый уровень.

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

Атрибуты security_level, используемые в RSBAC, это то, что обычно называется классификацией безопасности. В RSBAC 1.0.8 были добавлены категории, по причинам эффективности ограниченные множеством 64. С версии 1.0.9b количество security_level было увеличено до 253 (0-252, 8 Бит минус 3 специальных значения).

Текущий уровень безопасности (классификация) и текущий набор категорий процесса при необходимости устанавливаются автоматически, если включен флаг mac_auto, что является значением по умолчанию. Однако, как только активность процесса достигнет текущего уровня или набора категорий, mac_auto отключается.

Установка *-property выполнена с верхней и нижней границами, называемыми min_write и max_read. Эти значения переустанавливаются только для выполнения новой программы, а не во время ответвления/дублирования или закрытия файлов, так как только новое выполнение освобождает область памяти процесса.

Пожалуйста, имейте в виде, что с версии 1.1.0 все допуски записи, например: создание файла в DIR (CREATE на объекте DIR), производятся с учетом ограничения min_write. Это может привести к очень ограниченному допуску. Поэтому с версии 1.1.1 доступы на единичные записи CREATE и DELETE не устанавливаются в соответствии с границами min_write, если все еще выполняются MOUNT, APPEND_OPEN, READ_WRITE_OPEN, WRITE_OPEN и TRACE.

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

MAC атрибуты файла/каталога security_level и mac_categories могут быть унаследованы от родительского каталога. Для безопасности выравнивают значение, чтобы указать, что наследование от родителя - 5 (4 используется внутренне), для категорий, это является пустым набором (все биты 0). С версии 1.0.9b специальные значения security_level были подняты до 249, в настоящий момент 254 и 253.

RSBAC MAC-Light

Станислав Иевлев и я (Amon Ott, прим.переводчика) добавили параметр MAC называемый MAC-Light для упрощения использования модуля MAC. Вот изменения:

  1. Всегда разрешено создание объектов Файл/Каталог/Fifo

  2. Каждый пользователь может производить монтирование, если имеет достаточный для этого уровень допуска (разрешено к применению только системным администраторам)

Модель целостности Кларка - Уилсона (CWI)

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

Functional Control (FC)

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

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

Признак object_category для файла/каталога/fifo может быть унаследован от родительского каталога.

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

FC может быть полностью выражен RC моделью, так что это устарело. Установки RC, используемые по умолчанию, подобны этой модели.

Security Information Modification (SIM)

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

Признак data_type для файла/каталога может быть унаследован от родительского каталога.

Эта модель может быть использована как функциональный контроль только в комбинации с другими. Однако, информация, относящаяся к безопасности, может быть защищена от вмешательства системного администратора, что превышает возможности контроля доступа в стиле Unix.

SIM может быть полностью выражен RC моделью, так что это добро устарело.

Simone Fischer-Hubner's Privacy Model (PM)

Эта модель была представлена на 17ой Национальной Конференции Компьютерной Безопасности в Балтиморе, США, в 1994 году ее разработчиком Simone Fischer-Hubner. Это следствие из правил Федерального Немецкого Закона о Секретности и директивы ЕС о безопасности.

Модель и ее реализация в RSBAC детально описаны в наших отчетах по Конференции NISS 98.

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

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

Эта модель может быть использована для хранения и обработки персональных данных. Для защиты системных данных без администрирования наверху, рассматривая их как персональные данные, должна использоваться другая модель, например FC, SIM, RC или ACL.

Malware Scan (MS)

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

Если данные, особенно программы, перемещены из других систем, то во избежание широкого распространения инфекции должна быть использована эта модель. Однако, определен может быть только известный алгоритму сканнера инфицированный код. На Linux это вирус bliss, варианты A и B, и некоторые вирусы DOS. Платформозависимые макро- и ява вирусы будут включены позднее.

В настоящий момент это только рабочая демонстрационная модель, поскольку пока обнаружено слишком мало вирусов. Однако, при желании, довольно просто добавить большее количество строк поиска. Просто спросите в листе рассылки как это сделать. :)

Для дополнительной информации смотрите нашу документацию о Подходе к Обнаруженю Встроенного Вредоносного Программного Кода и Его Предупреждению (34КБ) для Третьего Скандинавского Симпозиума по Безопасным IT Системам (Nordsec'98).

File Flags (FF)

Эта модель определяет некоторые флаги доступа для файлов, fifo (нов. в 1.1.1) и каталогов. На сегодня поддерживаются следующие флаги:

execute_only FILE  
search_only DIR  
read_only FILE, FIFO, DIR  
write_only FILE, FIFO  
secure_delete FILE При удалении и усечении файл очищается (только ext2, msdos/vfat, minix)
no_execute FILE  
no_delete_or_rename FILE, FIFO, DIR новинка в 1.1.1, не унаследовано
add_inherited FILE, FIFO, DIR не унаследовано

Эти флаги проверяются каждый раз при доступе к объектам заданного типа. Изменять флаги может только пользователь в system_role 'security officer'.

Флаг add_inherited является специальным: если он указан, то к собственным флагам объекта будут добавлены флаги родительского каталога. Наследственность включена по умолчанию. Внимание: флаги no_delete_or_rename и add_inherited не могут быть унаследованы, они всегда должны быть установлены явно.

Пожалуйста, имейте ввиду, что атрибуты независимы друг от друга и разграничены: Все атрибуты, которые установлены или применены, например execute_only и no_execute вместе (или read_only и write_only) не приведут к появлению какого-либо доступа.

Флаги, выбранные для одних объектов, будут игнорированы другими. Это может быть использовано для установки search_only и execute_only на каталог, тогда вы сможете осуществлять ПОИСК (не ЧТЕНИЕ!) в этом каталоге и выполнять файлы, но ничего более.

Пример 1: Установите write_only на каталог журнала. Все файлы журнала, созданные в этом каталоге, унаследуют флаг write_only, таким образом журнал не будет прочитан до тех пор, пока этот флаг не убран.

Пример 2: Установите no_execute на /home. Все исполняемые файлы ниже этого каталога наследуют этот флаг, таким образом никто не сможет выполнять файлы в своих домашних каталогах, ока этот флаг не будет убран.

Пример 3: Установите no_delete_or_rename на /home. Домашние каталоги пользователей ниже этого каталога могут быть добавлены, удалены и индивидуально защищены, но родительский каталог /home не может быть перемещен или замещен для подделки других домашних каталогов для большинства пользователей.

Role Compatibility (RC) - Начиная с v1.0.9-pre3

Внимание: Это - описание более старой версии RC. Пожалуйста, для последних версий RSBAC, обращайтесь к новому руководству!

Это мощная и гибкая ролевая модель. Она определяет 64 RC-типа для объекта каждого типа (Файл/Каталог, Устройство, Межпроцессное Взаимодействие, Данные Системного Контроля) и 64 RC-роли для доступа к ним. Модуль RC был добавлен в RSBAC в версии 1.0.8.

Пожалуйста, также смотрите описание модели RC в RC-Paper.

Роли и Типы

Каждое вхождение роли имеет следующие поля:

Поле Вхождения Роли Типы/Значения Описание
name строка из 15 знаков Имя роли
role_comp 64 битный вектор Совместимые роли (1 Бит на роль) = процесс ролей могут изменяться на без chown (setuid)
type_comp_fd 64 битный вектор Совместимые типы файла/каталога (1 Бит на тип)
type_comp_dev 64 битный вектор Совместимые типы устройств
type_comp_process 64 битный вектор Совместимые типы процессов
type_comp_ipc 64 битный вектор Совместимые типы IPC
type_comp_scd 64 битный вектор Совместимые типы SCD
admin_type нету, системный или ролевой администратор Роль для администрирования RC роли/типа
def_fd_create_type Номер типа файла/каталога или специальное значение Тип новых файлов/каталогов
def_process_create_type Номер типа процесса или специальное значение Тип новых (ответвленных/дублированных) процессов
def_process_chown_type Номер типа процесса или специальное значение Тип процессов после chown (setuid)
def_process_execute_type Номер типа процесса или специальное значение Тип процессов после выполнения (запуск новой программы)
def_ipc_create_type Номер типа IPC или специальный флаг Тип нового канала IPC

Запись admin_type обозначает права администратора: none = нету, system admin = только чтение, role admin = полные. они не дают никаких других прав доступа, это сделано только для совместимости с окружением.

Типы вхождений имеют поле имени (длиной до 15 знаков). Только тип вхождения файл/каталог имеет дополнительную переменную type_fd_need_secdel, что обозначает безопасное удаление/усечение файлов этого типа.

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

Атрибуты RC

Каждый объект, не говоря уже об объектах пользователя, для обозначения своего типа получает атрибут rc_type. Для файлов и каталогов это поле может содержать специальное значение type_inherit_parent для обозначения наследственности атрибута.

Пользовательское вхождение получает атрибут rc_def_role, для определения начальной роли процесса после каждого CHOWN (setuid).

Вхождения процесса также имеют rc_role для текущей роли.

Вхождения Файл/Каталог имеют поле rc_force_role для обозначения форсированной роли, если этот файл выполнен. Этот механизм работает схоже с полями setuid или setgid в файловой системе Unix. Форсированная роль также может иметь одно из специальных значений.

Специальные Значения

Специальными значениями, о которых упоминалось выше, являются следующие:

Специальное Значение Роли Значение
role_inherit_user rc_def_role пользователя (владельца процесса)
role_inherit_process использование текущей rc_role процесса (удержание роли)
role_inherit_parent использование текущей rc_role родительского каталога или процесса

Тип Специального Значения Значение
type_inherit_process использование текущей rc_role процесса (удержание роли)
type_inherit_parent использование текущей rc_role родительского каталога или процесса
type_inherit_parent создание процесса/IPC не разрешено
type_no_execute выполнение другой программы не разрешено
type_use_new_role_def_create для процесса chown (setuid): использовать def_process_create_type новой роли

Начальная Конфигурация

Если запущено без определений ролей, то устанавливаются три предопределенных роли: General User (0), Role Admin (1) и System Admin (2). Установки для предопределенных ролей берутся из жестко встроенных установок в модуле FC.

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

В RSBAC, как правило, пользователь root (0) имеет rc_def_role 2 и пользователь 400 имеет rc_def_role 1, как предопределенное значение в useraci по умолчанию, содержащемся в пакете инструментария администратора.

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

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

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

Role Compatibility (RC) - С v1.0.9-pre4 и далее

Более старая модель RC была сильно изменена. Она все еще определяет 64 RC-типа для каждого объекта (Файл/Каталог, Устройство, Процесс, Межпроцессное Взаимодействие, Данные Контроля Системы) и до 64 RC-ролей для доступа к ним. Оригинальный модуль RC был добавлен в RSBAC версии 1.0.8.

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

Создание нового процесса является особым случаем в каждой модели контроля доступа. Здесь, каждая роль имеет вхождения для типов новых объектов, так же как вхождения для типа, регулирующего поведение на исполнение и изменение владельца процесса. Дополнительно, все эти вхождения имеют специальные значения, типа "no_create", которые отвергают подобные запросы.

Также, пожалуйста, смотрите описание модели RC в RC-Paper.

Вхождения Роли и Типа

Каждое вхождение роли имеет следующие поля:

Поле Вхождения Роли Тип/Значение Описание
имя строка из 15 знаков Имя роли
role_comp 64 битный вектор Подходящие роли (по 1 Биту на роль) = процессы ролей могут изменяться без chown (setuid)
type_comp_fd Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) Подходящие типы файлов/каталогов для запрошенных типов (1 Бит на тип и запрос) = значение True/False, к типу которого можно обращаться по запросу
type_comp_dev Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) Подходящие для запрошенных типов типы устройств (1 Бит на тип и запрос)
type_comp_process Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) Подходящие для запрошенных типов типы процессов (1 Бит на тип и запрос)
type_comp_ipc Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) Подходящие для запрошенных типов типы процессов (1 Бит на тип и запрос)
type_comp_scd Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) Подходящие для запрошенных типов типы SCD (1 Бит на тип и запрос)
admin_type нету, системный или ролевой администратор Роль для администрирования роли/типа RC
def_fd_create_type Номер типа file/dir или специальное значение Тип новых файлов/каталогов (для запрета создания используйте no_create, для выбранного типа требуются права CREATE)
def_process_create_type Номер типа процесса или специальное значение Тип новых (ответвленных/дублированных) процессов (для запрета создания используйте no_create, для выбранного типа требуются права CREATE)
def_process_chown_type Номер типа процесса или специальное значение Тип процесса после chown (setuid) (для запрета создания используйте no_chown)
def_process_execute_type Номер типа процесса или специальное значение Тип процесса после выполнения (старт новой программы) (для запрета создания используйте no_execute)
def_ipc_create_type Номер типа IPC или специальный флаг Типы новых каналов IPC (для запрета создания используйте no_create, для выбранного типа требуются права CREATE)

Вхождение admin_type указывает административные права RC для ролей, типов и специфических для RC атрибутов: none = нет доступа, системный администратор = только чтение, ролевой администратор = полный доступ. Они не дают никаких прав доступа объекту, это делается только подходящими установками.

Типы вхождений имеют поля имен (строка из 15 знаков). Только вхождения типа файл/каталог имеют дополнительное значение переменной type_fd_need_secdel, которые указывает на необходимость безопасного удаления/усечения файлов этого типа.

Типы SCD являются фиксированными и представляют одну область доступных системных данных каждый. Они также используются для административных прав, в данный момент только для auth_administration. Совместимость SCD означает доступность средств SCD. Вдобавок, специальный объект SCD 'other' используется для контроля целевых запросов типа NONE.

Атрибуты RC

Каждая отдельный объект со стороны пользовательских объектов для обозначения своего типа получает атрибут rc_type. Для файлов и каталогов это поле должно содержать специальное значение type_inherit_from от родительского для наследования сигнала атрибута.

Пользовательские вхождения получают атрибут rc_def_role, который используется для указания начальной роли процесса после каждого CHOWN (setuid).

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

Вхождения Файл/Каталог имеют поле rc_force_role для указания форсированной роли, если этот фаул выполнен. Этот механизм работает аналогично полям setuid или setgid в файловой системе Unix. Форсированная роль может также иметь одно из специальных значений (см. ниже). Значение форсированной роли копируется в атрибуты процесса для дальнейшего использования при запросах CHOWN.

Специальные Значения

Специальными значениями, упомянутыми ранее, являются следующие:

Специальное Значение Роли Предназначение
role_inherit_user использование пользовательских rc_def_role при CHOWN и EXECUTE (роль, форсированная по умолчанию с 1.0.9а-pre2)
role_inherit_process удержание текущей rc_role процесса при CHOWN и EXECUTE
role_inherit_parent наследование значения от родительского объекта, например родительского DIR
role_inherit_up_mixed удержание текущей rc_role процесса при EXECUTE, но с использованием новой rc_def_role владельца процесса при CHOWN (роль, форсированная по умолчанию с 1.0.9а-pre3)

Тип Специального Значения Предназначение
type_inherit_process использование текущей rc_type процесса (удержать тип)
type_inherit_parent использование текущего rc_type родительского каталога или процесса
type_no_create создание процесса/файла/каталога/IPC не разрешено
type_no_execute выполнение других программ не разрешено
type_no_chown изменение владельца процесса не разрешено
type_use_new_role_def_create для chown (setuid) процесса: использовать def_process_create_type новой роли

Начальная Конфигурация

Если запущено без определений роли, устанавливаются три предопределенных роли: General User (0), Role Admin (1) and System Admin (2). Получаются три предопределенных установки ролей из жестко встроенных установок в модуле FC.

Если запущено без установок типа, то устанавливаются по три типа на объект. Это тип по умолчанию “General” (0), который также используется как значение по умолчанию для всех атрибутов типа, тип “Security” (1) и тип “System” (2). На самом деле только “General” используется в установках по умолчанию, но примеры пригодности установлены для всех типов.

Как обычно в RSBAC, пользователь root имеет rc_def_role 2 и пользователь 400 имеет rc_def_role 1, как предустановленное значение в ACI установках пользователя по умолчанию.

Пожалуйста, помните: Предопределенные роли - это роли, созданные для того, чтобы вы могли начать. Они могут быть изменены как все другие роли! Вы можете запросто заблокировать себя, если измените их без достаточного понимания происходящего. Наиболее подходящий способ это, скопировав роль, производить изменения в новой роли.

Однако, режим обслуживания позволит вам изменять роли, если вы включите поддержку для обслуживания правил RC в конфигурации ядра.

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

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

Расширенное Администрирование с разделением обязанностей (с 1.0.9а-pre2 и далее)

Новейшие версии RC содержат сложную модель разделения обязанностей. Для этого были сделаны следующие дополнения:

  • Новый вектор роли admin_roles:

Какими ролями пользователь в этой роли может управлять. Некоторые установки роли далее ограничены другими правами, например role_comp и type_comp_xx.

  • Новый вектор роли assign_roles:

Какие роли пользователь в этой роли может читать и назначать пользователям и процессам (только процессам, если позволено MODIFY_ATTRIBUTE), и какие подходящие роли она может назначать администрируемым ролям (если assign_roles содержит все задействованные роли).

  • Дальнейшее ограничение на изменяющуюся роль пользователя/процесса: старая роль также должна содержаться в вашем векторе assign_roles. Таким образом, частичная роль назначающего всегда должна оставаться в пределах ограниченного набора ролей и не может затрагивать пользователей и процессы в других ролях.

  • Эти новые векторы могли быть изменены только Администрирующие Роли старого стиля. Если вы вначале их установите, и затем удалите все Администрирующие Роли, то это разделение зафиксируется навсегда (хорошо, до перезагрузки Maint ядра).

  • Права доступа нового типа:

ADMIN: Установить/удалить имя, установить need_overwrite для FD типов.

ASSIGN: Назначить этот тип объекту. Вам также необходим MODIFY_ATTRIBUTE на объектах старого типа.

ACCESS_CONTROL: Изменение нормальных (старых) прав доступа для этого типа для ваших администрированных ролей.

SUPERVISOR: Изменение этих новых специальных прав на этот тип для ваших администрированных ролей.

Если нет роли, имеющей право SUPERVISOR на тип, то разделение всегда зафиксировано (снова, пока не перезагружено Maint ядро, или кто-то все еще имеет административный тип Role-Admin старого типа).

  • Старые роли и типы (от старых версий RC) автоматически обновляются при первом запуске новой версии. При обновлении Администрирующие Роли просто получают любые установки. Предупреждение: если вы скопируете обновленную роль, то заодно будут получены любые установки для всех ролей и типов! Системный Администратор получит назначенные права только для его роли, которые должны позволить ему прочесть собственные установки роли, но не позволят что-либо изменить.

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

  • admin_type для Role_Admin старого типа все еще работает как и прежде, для сохранения вещей простыми для нормального использования.

Authentification Module (AUTH)

Основы

Этот модуль может быть рассмотрен как модуль поддержки для всех остальных модулей. Он ограничивает смену владельца для процессов (CHANGE_OWNER) на объектах процессов (setuid): запрос разрешен только если процесс имеет установленный флаг auth_may_setuid или в его наборе способностей находится целевой ID пользователя. Флаг auth_may_setuid и набор способностей наследуются при выполнении от программного файла.

Другими словами: Ни для какого процесса выполняющего любую программу не может быть разрешен setuid() вариант системного вызова, пока процесс (например наследованный от программного файла) имеет установленный флаг auth_may_setuid или возможность AUTH для целевого uid.

Возможности программных файлов могут быть установлены, если всем модулям разрешен запрос MODIFY_ATTRIBUTE для A_auth_add_f_cap или A_auth_remove_f_cap. Возможности процесса могут быть добавлены только другими процессами, которые имеет установленный флаг auth_may_set_cap, который также унаследован от их выполненного файла.

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

ПРЕДУПРЕЖДЕНИЕ: Если позволяется иметь без программы логина auth_may_setuid или набор возможностей и без серверного процесса устанавливающего возможности, то вы не сможете войти в систему! Используйте параметр ядра rsbac_auth_enable_login в критических случаях или при первой загрузке установите auth_may_setuid для /bin/login.

При задействованном AUTH, таким системным демонам, с setuid нормальной пользовательской учетной записи, как portmap, mysql или что нибудь еще, требуется явная возможность так делать. И они должны использовать только те uid которые вы разрешите.

Атрибуты AUTH

Все Процессы имеют два auth флага: auth_may_setuid и auth_may_set_cap с вышеупомянутыми значениями. Они унаследованы всеми детскими процессами.

Все файлы имеют те же самые два флага, которые заменяют таковые процесса при выполнении файла.

Файлы и процессы также имеют наборы возможностей с теми же самыми правилами наследования. Добавление к и при удалении от наборов возможностей ограничено в соответствии с различными схемами контроля доступа процессов и файлов: заголовки процесса могут быть установлены любым процессом, который имеет набор auth_may_set_flag, кто бы не был владельцем процесса. Флаги файла установлены от имени пользователей для любой программы.

Специальные Значения

До версии 1.0.9а, наборы возможностей файлов могли иметь специальное значение 65533 (UID -3), которое замещалось владельцем процесса во время копирования набора (время выполнения). Эти процессы могут вернуться назад к оригинальному ID пользователя посте его изменения. Это значение было изменено на 4294967292 (снова -3) в 1.0.9b, которое поддерживает 32 Битный ID пользователя.

Начальная Конфигурация

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

Как ссылку, вы можете использовать параметр ядра rsbac_auth_enable_login, который устанавливает auth_may_setuid (все права для изменения владельца процесса) для /bin/login. Это поведение усилено в структуре данных модуля AUTH.

Администрирование

AUTH только ограничивает его администрацию, если это позволено в конфигурации ядра. Администрация разрешена пользователю с system_role security_officer, и все задействованные атрибуты защищены.

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

Администрирование в основном основано на атрибутах файла и процесса и наборах возможностей обозначенных выше. Детали смотри в instadm.htm.

Access Control Lists Module (ACL)

Основы

Списки Контроля Доступа определяют какой субъект (пользователь, роль RC или группа ACL) к какому объекту (какого типа объекта) может иметь доступ с каким запросом (обычно запросами RSBAC и особенностями ACL).

Если здесь нет ACL вхождения для субъекта к объекту, то права к родительскому объекту унаследованы. Наследственность может быть ограничена масками наследственности.

Наверху иерархии наследственности находится значение ACL по умолчанию для каждого типа объекта (ФАЙЛ, КАТАЛОГ, ...).

Для изменения значения ACL объекта вам необходимы специальные права Контроля Доступа для этого объекта. Специальные права Forward позволяют дать права, которыми ва обладаете, кому-нибудь еще, но вы не сможете их в последствии отменить.

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

Поддерживаются все типы объекта. Только объекты IPC, USER и PROCESS имеют общий ACL по умолчанию, который всегда наследуется всеми объектами этого типа - эти объекты слишком недолговечны для администрирования полезных индивидуальных ACL.

От версии 1.0.9a, есть неизменная ACL группа Everyone (группа 0), которая по определению содержит всех легальных пользователей, таких как группы определенные пользователем.

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

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

Только упоминание: Пособия к другим сетевым PC системам могут быть не лишними ...;-)



[Источник ALT Linux Team]

[ опубликовано 22/10/2001 ]

ALT Linux Team - Перевод описания модулей RSBAC   Версия для печати