Версия для печати

Архив документации на OpenNet.ru / Раздел "Безопасность" (Многостраничная версия)

Перевод документации по RSBAC (Rule Set Based Access Control)

Перевод: Aleksandr Blokhin и Stanislav Ievlev

Первоисточник: sisyphus.ru/srpm/Sisyphus/rsbac-doc-ru


next up previous
Next: Совместимость

Rule Set Based Access Control (RSBAC) для Linux - Совместимость




next up previous
Next: Совместимость
next up previous
Next: Файловые Системы Up: Rule Set Based Access Previous: Rule Set Based Access

Совместимость

Работа RSBAC был проверена и подтверждена со многими параметрами ядра, другими патчами и программами. Некоторые из них приведены здесь. Однако, не может быть дано никакой гарантии, что эта информация верна или эта комбинация будет работать на вашей системе в соответствии с описанием.


next up previous
Next: Файловые Системы Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Прочие Возможности Up: Совместимость Previous: Совместимость

Файловые Системы

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


next up previous
Next: Прочие Возможности Up: Совместимость Previous: Совместимость
next up previous
Next: Исправления Безопасности Up: Совместимость Previous: Файловые Системы

Прочие Возможности


next up previous
Next: Исправления Безопасности Up: Совместимость Previous: Файловые Системы
next up previous
Next: Прочее Программное Обеспечение Up: Совместимость Previous: Прочие Возможности

Исправления Безопасности


next up previous
Next: Прочее Программное Обеспечение Up: Совместимость Previous: Прочие Возможности
next up previous
Next: Об Этом Документе Up: Совместимость Previous: Исправления Безопасности

Прочее Программное Обеспечение

Этот список все еще не полон и будет дополняться.


next up previous
Next: Об Этом Документе Up: Совместимость Previous: Исправления Безопасности
next up previous
Up: Rule Set Based Access Previous: Прочее Программное Обеспечение

Об Этом Документе

Составитель:

Перевод:


next up previous
Up: Rule Set Based Access Previous: Прочее Программное Обеспечение
next up previous
Next: Совместимость

Rule Set Based Access Control (RSBAC) для Linux - Совместимость




next up previous
Next: Совместимость

Rule Set Based Access Control (RSBAC) для Linux - Коды Ошибок



RSBAC возвращает определенные коды ошибки на внутренних функциях, аналогично системным вызовам RSBAC. Различаются следующие ошибки:

EPERM Тоже-самое, что и Linux EPERM: Доступ Запрещен.
EACCESS Внутренняя ошибка доступа к каталогу RSBAC
EREADFAILED Ошибка чтения с диска или из структуры данных
EWRITEFAILED Ошибка записи на диск или в структуры данных
EINVALIDPOINTER Был использован недопустимый параметр указателя (например NULL)
ENOROOTDIR Файловая система не имеет корневого каталога
EPATHTOOLONG Переполнение буфера слишком длинной строкой параметра
ENOROOTDEV Корневое устройство отсутствует или не доступно
ENOTFOUND Файлы или ACI-объекты не найдены
ENOTINITIALISED Вызов RSBAC до инициализации или после окончательной очистки
EREINIT RSBAC уже был инициирован
ECOULDNOTADDDEVICE Встроенная структура устройства не может быть добавлена, возможно нехватка памяти ядра
ECOULDNOTADDITEM Список объектов структур данных или proc-псевдо-файла не могут быть добавлены, возможно нехватка памяти ядра
ECOULDNOTCREATEPATH Каталог /rsbac в файловой системе создан быть не может
EINVALIDATTR Неверный номер параметра
EINVALIDDEV Неверное устройство
EINVALIDTARGET Неправильный тип объекта
EINVALIDVALUE Прочие ошибочные значения. Например, значение атрибута выходит за пределы диапазона
EEXISTS Объект уже существует
EINTERNONLY Значение должно использоваться только как внутреннее. Например, sec_level rsbac_internal
EINVALIDREQUEST Неверный номер запроса
ENOTWRITABLE Файловая система доступна только для чтения, параметры не были сохранены.
EMALWAREDETECTED (Более не используется по причине несовместимости со стандартами/программами Unix). Чтение из доменного подключения запрещено в результате обнаружения вредоносного программного кода
ENOMEM Недостаточно памяти (GFP_KERNEL)
EDECISIONMISMATCH Rsbac_adf_set_attr вызвал запрос, который rsbac_adf_request не должен был предоставить, вероятно в связи с изменением тем временем атрибута
EINVALIDVERSION Предпринята REG-регистрация для другой версии интерфейса REG.


Перевод: Александр Блохин <sass@uustoll.ee>


next up previous
Next: Пример использования модуля RSBAC

Rule Set Based Access Control (RSBAC) для Linux - Демонстрационный Образец PM




next up previous
Next: Пример использования модуля RSBAC
next up previous
Next: Цели демонстрации Up: Rule Set Based Access Previous: Rule Set Based Access

Пример использования модуля RSBAC PM (Privacy Model)

В демонстрационных целях в соавторстве с Simone Fischer-Hubner (http://agn-www.informatik.uni-hamburg.de/people/fischer) был создан пример простой программы. Не смотря на то, что в нем задействованы несколько моделей, наше внимание целиком сфокусировано на PM (privacy model), как наиболее полной и мощной. Остальные модели используются для специальных целей.


next up previous
Next: Цели демонстрации Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Преобразование в Privacy Model Up: Пример использования модуля RSBAC Previous: Пример использования модуля RSBAC

Цели демонстрации

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

Хранение и обработка данных выполнены в пределах одной защищенной системы без отдаленного доступа снаружи и передачи другим системам. Единственные исключения - передача данных составления счетов к медицинской страховой компании пациента и необходимой передаче данных диагноза к другому центру лечения. Оба требуют безопасного сетевого соединения.

Пациент при поступлении на лечение проходит следующий путь:

  1. Прием в регистратуре
  2. Диагностика и назначение метода лечения специалистом
  3. Хирургическое вмешательство или передача в другой лечебный центр
  4. Восстановительная терапия
  5. Выписка из медицинского учреждения
  6. Составление счетов к медицинской страховой компании пациента


next up previous
Next: Преобразование в Privacy Model Up: Пример использования модуля RSBAC Previous: Пример использования модуля RSBAC
next up previous
Next: Другие Модели Up: Пример использования модуля RSBAC Previous: Цели демонстрации

Преобразование в Privacy Model

Прежде всего определим объекты хранения данных и их задачи:

Цели Лечение Организация Исследования
Задачи Диагноз Прием Статистика
  Операция Выписка  
  Терапия Счета  
  Передача Передача Информации  


Для хранения классов объекта требуются:

Классы объекта Цели Содержание
Регистратурные данные Организационные Основные данные пациента
Данные для счета Организационные Данные необходимые для составления счетов
Диагноз Лечение Данные диагноза
Показания к лечению Лечение Инструкции для хирургов и терапевтов
Данные хирургического вмешательства Лечение Протокол операции
Данные лечения Организационные, Лечение Протокол оздоровительных процедур
Статистика Исследование Статистика операций


Следующим шагом назначаем и авторизуем пользователей для этих операций:

Пользователь Авторизованное Задание
Специалист Диагностика, Терапия, Передача
Хирург Оперирование, Передача
Терапевт Терапия
Клерк Регистрация, Выписка
Бухгалтер Счета, Передача Информации
Ученый Статистика


Обработка данных производится в соответствии с процедурами преобразования (ПП):

ПП Используются для
pm_create Создание файлов с данными классов
Appending editor Добавление текста к существующему файлу
Editor Измение текстового файла
Display program Вывод текстового файла на экран
Deletion program Удаление файла
Transfer program Защищенная передача данных для межпроцессного взаимодействия
Statistics program Чтение файлов, подсчет статистики, запись их результатов в другой файл


Следующий этап является определением всех авторизованных ПП для всех задач:

Задача Авторизованная ПП
Диагноз pm_create, Appending editor, Editor, Display program
Операция pm_create, Appending editor, Editor, Display program
Терапия Appending editor, Display program
Перевод Transfer program
Регистрация pm_create, Editor
Выписка Appending editor
Расчет Editor, Display program
Передача Информации Transfer program
Статистика pm_create, Editor, Statistics program


И наконец назначение всех необходимых прав доступа. Вероятные типами доступа являются Read, Write, Delete, Create и Append.

Задача Класс объекта ПП Допуски
Диагноз Диагноз pm_create Create
Диагноз Диагноз Editor Read, Write, Append
Диагноз Диагноз Display program Read
Диагноз Данные о действиях Appending editor Append
Диагноз Процедуры pm_create Create
Диагноз Процедуры Editor Read, Write, Append
Операция Процедуры Display program Read
Операция Операционные данные pm_create Create
Операция Операционные данные Editor Read, Write, Append
Операция Данные о действиях Appending editor Append
Терапия Процедуры Display program Read
Терапия Данные о действиях Appending editor Append
Передача Диагноз Transfer program Read
Передача Процедуры Transfer program Read
Передача Межпроцессное Взаимодействие Transfer program Create, Write, Append
Регистрация Регистратурные данные pm_create Create
Регистрация Регистратурные данные Editor Read, Write, Append
Регистрация Данные о действиях pm_create Create
Регистрация Данные о действиях Appending editor Append
Выписка Регистратурные данные Appending editor Append
Выписка Данные о действиях Appending editor Append
Расчет Данные о действиях Display program Read
Расчёт Расчетные данные pm_create Create
Расчёт Расчетные данные Editor Read, Write, Append
Передача Информации Данные счетов Transfer program Read
Передача Информации Межпроцессное Взаимодействие Transfer program Create, Write, Append
Статистика Статистическая информация pm_create Create
Статистика Статистическая информация Editor Read, Write, Append
Статистика Статистическая информация Deletion program Delete
Статистика Статистическая информация Statistics program Write, Append
Статистика Диагноз Statistics program Read
Статистика Процедуры Statistics program Read
Статистика Операционные данные Statistics program Read


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


next up previous
Next: Другие Модели Up: Пример использования модуля RSBAC Previous: Цели демонстрации
next up previous
Next: Стадии Лечения с Точки Up: Пример использования модуля RSBAC Previous: Преобразование в Privacy Model

Другие Модели

Так как Privacy Model защищает только личные данные и системные вызовы, то для защиты других данных используется дискретный контроль доступа, реализуемый другой моделью безопасности (в рамках RSBAC дискреционный контроль доступа реализуется с использованием ACL или FF). Также, по крайней мере, идентификация и файл аутентификации /etc/shadow должны быть объявлены как личные данные с их собственным классом объекта, таким образом доступ предоставляется только авторизованным программам.

Для ограничения доступа к файлам в этом примере может быть использован Functional Control (данная модель считается устаревшей так как ее возможности перекрываются другим модулем (RC)). В этой модели системные объекты и объекты категорий безопасности доступны только офицерам безопасности (не обязательно, что бы это были одни и те же лица, что и в PM) и администраторам. Если должно предотвращаться только неавторизованное изменение, например в /etc/passwd, то для этих целей должно быть достаточно модели Security Information Modification с ее атрибутом data type (данная модель также считается устаревшей так как ее возможности перекрываются (RC)).

Дополнительно, для конфиденциальности деловой информации, должна использоваться Mandatory Model (мандатный доступ - модуль MAC).


next up previous
Next: Стадии Лечения с Точки Up: Пример использования модуля RSBAC Previous: Преобразование в Privacy Model
next up previous
Next: Об Этом Документе Up: Пример использования модуля RSBAC Previous: Другие Модели

Стадии Лечения с Точки Зрения Системы

Прохождение пациента через медицинский центр характеризуется следующими стадиями:

  1. Регистратор регистрирует пациента. Он создает файл данных о действиях при помощи процедуры преобразования pm_create и файл для данных о назначенных процедурах при помощи ПП editor, добавляя сведения о процедурах в файл с данными о действиях.
  2. Специалист создает файл диагноза и использует editor для записи и изменения диагноза. Он создает и заполняет файл инструкций по лечебному процессу для данного пациента при помощи editor, внося в него при необходимости изменения. В конце он добавляет свои действия в файл данных о действиях. При необходимости он направляет пациента к другому специалисту или в другой медицинский центр. С этой целью он может переслать диагноз и показания к лечению при помощи transfer program.
  3. Хирург читает показания к лечению при помощи display program и оперирует пациента. Впоследствии он создает и редактирует файл данных операции, составляет протокол операции. Как и ранее, все действия добавляются в файл действий. Как и специалист, хирург может направить пациента к другому специалисту или в другой медицинский центр. С этой целью он также может переслать диагноз и показания к лечению при помощи transfer program.
  4. Терапевт также читает показания к лечению, работает с пациентом и добавляет отчет о проделанных действиях в файл действий.
  5. Когда лечение закончено, пациент проходит процедуру выписки чиновником, который завершает данные регистрации и действий при помощи append editor.
  6. И на последок, бухгалтер читает файл действий, составляет и редактирует файл расчетов, который он пересылает медицинской страховой компании пациента при помощи transfer program.
  7. Диагнозы, показания к лечению и операционные данные могут быть прочитаны исследовательской статистической программой, создающей статистические данные. Чтение других данных для исследования требует согласия пациента. Файлы данных статистики могут быть созданы, изменены и удалены только пользователями, у которых текущим заданием является статистика.


next up previous
Next: Об Этом Документе Up: Пример использования модуля RSBAC Previous: Другие Модели
next up previous
Up: Пример использования модуля RSBAC Previous: Стадии Лечения с Точки

Об Этом Документе

Составители:

Перевод:

next up previous
Up: Пример использования модуля RSBAC Previous: Стадии Лечения с Точки
next up previous
Next: Пример использования модуля RSBAC

Rule Set Based Access Control (RSBAC) для Linux - Демонстрационный Образец PM




next up previous
Next: Пример использования модуля RSBAC
next up previous
Next: Пример Privacy Model

Rule Set Based Access Control (RSBAC) для Linux - Примеры




next up previous
Next: Пример Privacy Model
next up previous
Next: Защита от подделки исполняемых Up: Rule Set Based Access Previous: Rule Set Based Access

Пример Privacy Model

Этот пример описан в отдельном документе - Пример Privacy Model [*].



next up previous
Next: Защита от подделки исполняемых Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Решение с помощью модуля Up: Защита от нежелательного Выполнения Previous: Административные цели

Действия, выполняемые для всех моделей


next up previous
Next: Решение с помощью модуля Up: Защита от нежелательного Выполнения Previous: Административные цели
next up previous
Next: Решение с помощью модуля Up: Защита от нежелательного Выполнения Previous: Действия, выполняемые для всех

Решение с помощью модуля FF

  1. Удалите все add_inherited-флаги для всех идентифицированных каталогов.
  2. Удалите все add_inherited-флаги для всех идентифицированных файлов и библиотек в отдельности.
  3. Установите флаг no_execute на каталог верхнего уровня
  4. Флаг no_execute без add_inherited не будет наследоваться и не будет назначен идентифицированным каталогам и исполняемым файлам в отдельности.


next up previous
Next: Решение с помощью модуля Up: Защита от нежелательного Выполнения Previous: Действия, выполняемые для всех
next up previous
Next: Решение с помощью модуля Up: Защита от нежелательного Выполнения Previous: Решение с помощью модуля

Решение с помощью модуля RC

  1. Выполните действия 1-5 из способа для RC (смотри выше) в той же последовательности. Произведите похожую настройку для каталогов и файлов библиотек для типа 'Libraries'.
  2. Удалите права EXECUTE для всех ролей на все типы, отличные от 'Executables' и 'Libraries'. Для проверки настроек удалите эти права для вашей роли Role Admin и попробуйте другие роли.


next up previous
Next: Решение с помощью модуля Up: Защита от нежелательного Выполнения Previous: Решение с помощью модуля
next up previous
Next: Об Этом Документе Up: Защита от нежелательного Выполнения Previous: Решение с помощью модуля

Решение с помощью модуля ACL

  1. Предоставьте для группы 0 ('Everyone') права SEARCH и EXECUTE на все идентифицированные файлы и каталоги.
  2. Если вам необходимо использование READ_OPEN файлов, например для библиотек или сценариев оболочки, то добавьте права READ_OPEN и CLOSE.
  3. Для возможности дополнения оболочкой имен файлов вам необходимы права READ и, возможно, GET_STATUS_DATA или GET_PERMISSIONS_DATA.
  4. Удалите права EXECUTE из шаблона наследования для корневого каталога / или из всех вхождений в acl по умолчанию для FD.
  5. Если вы имеете индивидуальные ACL-вхождения на любых каталогах или файлах, отличных от тех, которые уже были идентифицированы, то вы должны отобрать от них права EXECUTE. Вы можете найти все ACL-вхождения при помощи acl_tlist -r.
  6. Так как права SUPERVISOR включают в себя все прочие права и (обычно) могут не маскироваться, все субъекты с SUPERVISOR на верхние уровни все-равно имеют полный доступ. При стандартной настройке только пользователь 400 (Security Officer) имеет доступ к FD для ACL по умолчанию (и следовательно ко всем файлам и каталогам).


next up previous
Next: Об Этом Документе Up: Защита от нежелательного Выполнения Previous: Решение с помощью модуля
next up previous
Up: Пример Privacy Model Previous: Решение с помощью модуля

Об Этом Документе

Составители:

Перевод:


next up previous
Up: Пример Privacy Model Previous: Решение с помощью модуля
next up previous
Next: Административная цель Up: Пример Privacy Model Previous: Пример Privacy Model

Защита от подделки исполняемых файлов




next up previous
Next: Административная цель Up: Пример Privacy Model Previous: Пример Privacy Model
next up previous
Next: Действия, выполняемые для всех Up: Защита от подделки исполняемых Previous: Защита от подделки исполняемых

Административная цель

Защита всех исполняемых файлов, например в /sbin, от подмены


next up previous
Next: Действия, выполняемые для всех Up: Защита от подделки исполняемых Previous: Защита от подделки исполняемых
next up previous
Next: Решение с помощью модуля Up: Защита от подделки исполняемых Previous: Административная цель

Действия, выполняемые для всех моделей


next up previous
Next: Решение с помощью модуля Up: Защита от подделки исполняемых Previous: Административная цель
next up previous
Next: Решение с помощью модуля Up: Защита от подделки исполняемых Previous: Действия, выполняемые для всех

Решение с помощью модуля FF

  1. Установите ff_flags для всех идентифицированных каталогов в значение search_only и read_only. Флаг search_only означает, что вы получите доступ к любому объекту в каталоге только при условии, что вы знаете его полное название, и что вам не позволено что-либо модифицировать в этом каталоге.
  2. Установите read_only для всех идентифицированных исполняемых файлов в отдельности. Флаг read_only обозначает, что каталог со всеми его подобъектами доступен в режиме <<только для чтения>>.
  3. Если вам необходим доступ к каталогу на чтение, то удалите флаг search_only. Флаг read_only при этом остается.
  4. Если каталог содержит только исполняемые файлы и не содержит сценариев оболочки, то вы можете использовать для него флаг execute_only. Это означает, что все файлы, находящиеся в этом каталоге, могут быть выполнены, но не могут быть прочитаны или скопированы. (В ALT Linux Сastle - при настройке замкнутой программной среды для сценариев используется read_only для всех остальных -execute_only)


next up previous
Next: Решение с помощью модуля Up: Защита от подделки исполняемых Previous: Действия, выполняемые для всех
next up previous
Next: Решение с помощью модуля Up: Защита от подделки исполняемых Previous: Решение с помощью модуля

Решение с помощью модуля RC

  1. Создайте новый FD-тип 'Executables'.
  2. Назначте всем ролям для этого типа права SEARCH и EXECUTE.
  3. Если вам необходимо использование READ_OPEN файлов, например для сценариев оболочки, то добавьте права READ_OPEN и CLOSE.
  4. Для возможности дополнения оболочкой имен файлов вам необходимы права READ и, возможно, GET_STATUS_DATA или GET_PERMISSIONS_DATA.
  5. Установите для всех идентифицированных каталогов и файлов новый FD-тип 'Executables'.
  6. Если вы хотите разрешить какой-то роли, например 'Installer', изменение или установку исполняемых файлов, вы можете это сделать простым добавлением необходимых прав к типу 'Executables' этой роли.


next up previous
Next: Решение с помощью модуля Up: Защита от подделки исполняемых Previous: Решение с помощью модуля
next up previous
Next: Защита от нежелательного Выполнения Up: Защита от подделки исполняемых Previous: Решение с помощью модуля

Решение с помощью модуля ACL

  1. Установите шаблон наследования для SEARCH и EXECUTE только для идентифицированных файлов и каталогов.
  2. Если вам необходимо использование READ_OPEN файлов, например для сценариев оболочки, то добавьте права READ_OPEN и CLOSE.
  3. Для возможности дополнения оболочкой имен файлов вам необходимы права READ и, возможно, GET_STATUS_DATA или GET_PERMISSIONS_DATA.
  4. Так как права SUPERVISOR включают в себя все прочие права и (обычно) могут не маскироваться, все субъекты с SUPERVISOR на верхние уровни все-равно имеют полный доступ. При стандартной настройке только пользователь 400 (Security Officer) имеет доступ к FD для ACL по умолчанию (и следовательно ко всем файлам и каталогам).
  5. Если вы хотите разрешить субъектам, например группе 'Installers', изменение или установку исполняемых файлов, вы можете это сделать простым добавлением необходимых прав каталогу или ACL файла.
  6. Если позднее вы захотите убедиться, что не забыли такие вхождения, то вы можете найти все ACL-вхождения при помощи acl_tlist -r.


next up previous
Next: Защита от нежелательного Выполнения Up: Защита от подделки исполняемых Previous: Решение с помощью модуля
next up previous
Next: Административные цели Up: Пример Privacy Model Previous: Решение с помощью модуля

Защита от нежелательного Выполнения




next up previous
Next: Административные цели Up: Пример Privacy Model Previous: Решение с помощью модуля
next up previous
Next: Действия, выполняемые для всех Up: Защита от нежелательного Выполнения Previous: Защита от нежелательного Выполнения

Административные цели

  1. Защита неподконтрольных файлов или библиотек от выполнения.


next up previous
Next: Действия, выполняемые для всех Up: Защита от нежелательного Выполнения Previous: Защита от нежелательного Выполнения
next up previous
Next: Пример Privacy Model

Rule Set Based Access Control (RSBAC) для Linux - Примеры




next up previous
Next: Пример Privacy Model
next up previous
Next: Установка и Администрирование

Rule Set Based Access Control (RSBAC) для Linux - Установка и Администрирование




next up previous
Next: Установка и Администрирование
next up previous
Next: Ядро Up: Rule Set Based Access Previous: Rule Set Based Access

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

Исходные тексты RSBAC разбиты на три части, находящиеся по адресу http://www.rsbac.org/code/, которые устанавливаются отдельно:

  1. расширения для ядра в файле rsbac-*.tar.gz
  2. патчи ядра для подключения расширений к ядру в файлах patch-x.y.z.gz
  3. инструментарий для администрирования в файлах rsbac-admin-*.tar.gz,
Все исходные тексты могут быть получены через Интернет с домашней страницы RSBAC - http://www.rsbac.org

Для новичков также существует хорошая документация RSBAC for Beginners, по адресу http://linux.ru.net/inger/RSBAC-DOC.html


next up previous
Next: Ядро Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Административный Инструментарий Up: Установка Previous: Обновление RSBAC


Параметры Ядра

Lilo (Milo на alpha) позволяет при загрузке передавать ядру дополнительные параметры. Большинство из них по умолчанию задает отладочный режим работы, который может быть изменен позднее через syscall или proc-интерфейс. RSBAC-система акцептирует следующие, не являющиеся структурами данных, принудительные или связанные с принятием решения отладочные или вспомогательные параметры (для дополнительной информации смотрите README-kernparm):


next up previous
Next: Административный Инструментарий Up: Установка Previous: Обновление RSBAC
next up previous
Next: Установка Up: Ядро Previous: Параметры Ядра

Административный Инструментарий




next up previous
Next: Установка Up: Ядро Previous: Параметры Ядра
next up previous
Next: Общее Администрирование Up: Административный Инструментарий Previous: Административный Инструментарий

Установка

Административный инструментарий из файла rsbac-admin-*.tar.gz может быть распакован при помощи команды tar xvzf rsbac-admin-*.tar.gz в один каталог, например /root/rsbac. После выполнения configure (с v1.1.2), просто make создаст инструментарий и make install установит его. make allclean, впоследствии, очистит ваш каталог. С версии 1.0.9а make install также создает, при необходимости, файл /rsbac/useraci, который вам необходим для загрузки и администрирования.

Если компиляция с egcs не удалась из-за register error, попытайтесь удалить из Makefile параметр оптимизации -О2 (смотри комментарий). Это ошибка оптимизации egcs.

При установке инструментария в версиях RSBAC до 1.0.9b вы не должны иметь ни активного RSBAC-ядра, ни ремонтного ядра, так как при этом файл useraci был бы скопирован в каталог /rsbac. С версии 1.0.9b, если этот файл отсутствует, ядро само создает стандартную настройку пользователя.

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

Средства меню нуждаются в диалоговом инструментарии, который является частью большинства дистрибутивов Linux. Если вы намереваетесь использовать инструментарий основанный на меню на не-80x25 мониторах, тогда вы должны включить в свой стартовый bash-файл, например /etc/profile, экспорт для LINES и COLUMNS для получения большего размера изображения.


next up previous
Next: Общее Администрирование Up: Административный Инструментарий Previous: Административный Инструментарий
next up previous
Next: Администрирование Privacy Module (PM) Up: Административный Инструментарий Previous: Установка

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

Общее администрирование осуществляется средствами командной строки или при помощи диалоговых меню. Напрямую, к RSBAC-файлам обращаться нельзя. Многие параметры могут быть проконтролированы и установлены во время работы, если это задействовано в конфигурации ядра, через proc-интерфейс в proc/rsbac-info (смотри README-proc в Documentation/rsbac). Все средства командной строки используют новые системные вызовы, предоставляемые пакетом RSBAC, и все проверки доступа делаются в пределах ядра. Однако, эти инструменты делают некоторую проверку здравомыслия.

Каждый инструмент печатает короткую справку, если он вызывается с недостаточными параметрами. В настоящее время предоставляются следующие инструменты:

В отличие от Privacy Model, Role Compatibility-модели, AUTH-модели и ACL-модели, администрирование модулей принятия решений может быть выполнено только через установку общих атрибутов. Эти модули ограничивают доступ к их атрибутам в основном пользователями в системной роли Security Officer, который установлен при инсталляции для пользователя 400. Если офицер безопасности не определен, то для назначения ролей должно быть использовано ремонтное ядро, как описано выше.

RC-модуль администрируется при помощи атрибутов и определений роли и типа с использованием средств администрации RC.

ACL-модуль администрируется через установки попечителя и маски для субъектов и объектов различных типов. Они устанавливаются при помощи acl_grant и acl_mask, административного инструментария ACL , и считываются с acl_tlist и acl_rights. Никакие общие атрибуты не применяются. Рекомендуются ACL-меню.

Атрибуты, так же как и содержащие их типы данных для системных вызовов (смотри types.h, pm_types.h и rc_types.h), определены и описаны на странице описания моделей [*] и в руководстве пользователя syscall. Точное описание синтаксиса и кодов для числовых значений атрибутов включены в относящуюся к ним справку в инструментарии (вызов без параметров).


next up previous
Next: Администрирование Privacy Module (PM) Up: Административный Инструментарий Previous: Установка
next up previous
Next: Администрирование Role Compatibility Module Up: Административный Инструментарий Previous: Общее Администрирование

Администрирование Privacy Module (PM)

Пока этот модуль активен, общие средства (и системные вызовы) для установки атрибутов не действуют для любого подходящего отдельного атрибута. Напротив, все администрирование выполняется средствами rsbac_pm, который является просто интерфейсом для системных rsbac_pm-вызовов основанных на бюллетенях. Эта программа также акцептирует имена как значения, например security_officer для функции set_role. К сожалению все еще не существует меню-ориентированного инструментария - все еще ищем добровольцев...

Поскольку само назначение PM-ролей основанное на бюллетенях, выполненное офицером защиты данных, используется офицером безопасности, эти PM-роли, назначенные при помощи атрибута pm_role, должны иметь два различных пользователя. Это автоматически делается при установке для пользователя 400 (офицер защиты, как системная роль) и 401 (офицер защиты данных). Если этого не произошло, загрузитесь с ремонтным ядром и вызовите

attr_set_up USER pm_role system_administrator 0 

attr_set_up USER pm_role security_officer 400 

attr_set_up USER pm_role data_protection_officer 401

Для указания и назначения TP-значений должен быть определен TP-менеджер и также назначена его роль.


next up previous
Next: Администрирование Role Compatibility Module Up: Административный Инструментарий Previous: Общее Администрирование
next up previous
Next: Администрирование Access Control Lists Up: Административный Инструментарий Previous: Администрирование Privacy Module (PM)

Администрирование Role Compatibility Module (RC)

Администрирование RC может быть выполнено из командной строки через rc_get_item, rc_set_item и rc_copy_role. Рекомендуемый путь однако состоит в том, чтобы использовать инструменты базирующиеся на диалоговом меню, rsbac_rc_role_menu и rsbac_rc_type_menu, которые обеспечивают командам удобный графический интерфейс.

Перед началом администрирования убедитесь, что вы понимаете описания моделей, представленные на странице описания соделей - models.html. Тогда использование инструментов будет эффективным.

Если необходимые определения ролей для пользователя root (0) и 400 не установлены, загрузитесь с ремонтным ядром и вызовите

attr_set_up USER rc_def_role 2 0 

attr_set_up USER rc_def_role 1 400. 

В этом примере использованы предопределенные роли System Admin (2) и Role Admin (1).


next up previous
Next: Администрирование Access Control Lists Up: Административный Инструментарий Previous: Администрирование Privacy Module (PM)
next up previous
Next: Другие Программы Up: Административный Инструментарий Previous: Администрирование Role Compatibility Module

Администрирование Access Control Lists Module (ACL)

Для администрирования ACL предназначены средства командной строки acl_rights, acl_grant, acl_mask и acl_tlist. Каждый кто знаком с администрированием Netware 3.xx (tm) не найдет разницы после просмотра описания моделей на странице [*]. Всем остальным крайне желательно изучить описание моделей перед внесением каких-либо изменений.

Также имеются два интерактивных средства, rsbac_acl_menu и rsbac_acl_group_menu, которые могут облегчить жизнь.


next up previous
Next: Другие Программы Up: Административный Инструментарий Previous: Администрирование Role Compatibility Module
next up previous
Next: Как Выполнять Резервное Копирование Up: Ядро Previous: Администрирование Access Control Lists

Другие Программы

В комплект для администрирования также включены некоторые другие программы, которые описаны здесь. Конечно, они также имеют ограничения по контролю доступа.




next up previous
Next: Как Выполнять Резервное Копирование Up: Ядро Previous: Администрирование Access Control Lists
next up previous
Next: Демонстрационные Примеры RSBAC Up: Другие Программы Previous: Другие Программы


Как Выполнять Резервное Копирование и Восстановление

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

После этого вы можете использовать attr_back_fd, attr_back_dev и attr_back_user для создания резервных копий всех атрибутов назначенных вами в файлы восстановительных сценариев оболочки.

Если задействовано AUTH, вы можете использовать auth_back_cap для резервирования файловых возможностей.

Восстановительный сценарий RC производится с 'rc_get_item backup'.

Для ACL-модели используйте acl_tlist, acl_mask и acl_group с параметром -b для воспроизведения восстановительных сценариев. Обратите пожалуйста внимание, что все пользователи должны делать резервное копирование собственных списков групп с участниками, поскольку другие пользователи не имеют к ним никакого доступа. С 1.1.2 они могут использовать сценарий acl_backup_my_groups, находящийся в каталоге examples/acl/ административного инструментария.

Административный инструментарий содержит сценарий backup_all, который попытается воспроизвести сценарий резервного копирования в основном всех установок RSBAC для всех модулей, за исключением PM (смотри ниже). Опять же, резервное копирование ACL-групп таким способом невозможно - надо либо позволить всем пользователям копировать их группы, либо копировать резервные proc-файлы.

Затем для резервирования файлов вы используете нормальные tar-подобные команды. Если вы используете PM-модуль, то вы должны также копировать /rsbac/pm_* из-под не-RSBAC ядра, так как в настоящий момент другого способа резервного копирования не существует.

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

Если вы используете PM-модуль, то вы должны установить старые pm_* файлы в /rsbac из-под не-RSBAC ядра. Если вы используете ACL, вы должны копировать в /rsbac acl_grp и acl_gm файлы. Все остальные установки восстанавливаются выполнением восстановительных сценариев. Обратите пожалуста внимание, что ACL-группы восстанавливаются их настоящими владельцами, иначе их владельцем станет пользователь выполняющий сценарий восстановления Разумеется, восстанавливающий пользователь позднее может передать права владения.


next up previous
Next: Демонстрационные Примеры RSBAC Up: Другие Программы Previous: Другие Программы
next up previous
Next: Об Этом Документе Up: Ядро Previous: Как Выполнять Резервное Копирование

Демонстрационные Примеры RSBAC

В демонстрационных целях вместе с Simone Fischer-Hubner (http://agn-www.informatik.uni-hamburg.de/people/fischer) были созданы программные примеры простой Privacy Model (PM) [*]. Хотя и используются некоторые модули, наше внимание сфокусировано на моделях секретности, являющихся наиболее полными и в то же время мощными. Другие модули используются в специальных целях.

Некоторые другие примеры находятся в документе Примеры [*].


next up previous
Next: Об Этом Документе Up: Ядро Previous: Как Выполнять Резервное Копирование
next up previous
Next: Установка Up: Rule Set Based Access Previous: Установка и Администрирование

Ядро




next up previous
Next: Установка Up: Rule Set Based Access Previous: Установка и Администрирование
next up previous
Up: Ядро Previous: Демонстрационные Примеры RSBAC

Об Этом Документе

Составитель:

Перевод:


next up previous
Up: Ядро Previous: Демонстрационные Примеры RSBAC
next up previous
Next: а) Приложение большого патча Up: Ядро Previous: Ядро

Установка

Для установки вы должны иметь развернутое дерево исходных текстов поддерживаемого ядра. Исходные тексты ядра доступны на http://www.kernel.org. Архив может быть распакован в каталог /usr/src с использованием команды tar xvzf linux-2.x.y.tar.gz. При этом будет создан подкаталог linux, который должен быть переименован, например, в linux-2.x.y-rsbac только затем, чтобы избежать ошибок в дальнейшем. Если у вас уже существует файл или каталог с названием linux, то он должен быть удален или переименован еще до начала распаковки архива. Для создания дерева исходников вам понадобится приблизительно 120 МВ свободного места на диске для ядра версии 2.2.18 и 160 МВ для ядра версии 2.4.2, включая RSBAC и объектные файлы.




next up previous
Next: а) Приложение большого патча Up: Ядро Previous: Ядро
next up previous
Next: b) Установка из tarball Up: Установка Previous: Установка

а) Приложение большого патча (старая поставка в виде большого патча, до v1.0.8а)

После этого, rsbac-patch-*.gz может быть извлечен из архива при помощи команды gzip -d rsbac-patch-*.gz. Файл rsbac-patch-* вы также должны затем переместить в каталог /usr/src. Если вы используете существующие исходные тексты в других целях, то, прежде чем использовать патч, сделайте их резервную копию, так как патч является необратимым. Затем вы должны приложить этот патч в основном каталоге ядра /usr/src/linux-2.2.xxx-rsbac введя команду patch -p1 </usr/src/rsbac-patch-* SPMamp;>/usr/src/err.

Когда патч будет наложен, в /usr/src/err вы найдете протокол. Если в нем имеются какие-либо отклонения (ищите в протоколе строки с failed), то вы должны удалить дерево исходных текстов и повторить всю процедуру заново. Если это все-еще не выходит как надо, пожалуйста, напишите мне (ao@rsbac.org, Amon Ott, прим.переводчика) или в список рассылки RSBAC (rsbac@rsbac.org) об этом - это ошибка и она больше никогда не должна повториться!

Если перед этим дерево исходников ядра претерпело изменения, то наличие отклонений более чем вероятно. В этом случае протокол и файлы *.rej помогут вам приложить оставшуюся часть вручную. Прежде, чем приложить патч, прочитайте Documentation/rsbac/README-patching! Уверен, что прежде чем начать вы произвели резервное копирование, не так ли?


next up previous
Next: b) Установка из tarball Up: Установка Previous: Установка
next up previous
Next: Конфигурация и Сборка Ядра Up: Установка Previous: а) Приложение большого патча

b) Установка из tarball (начиная с v1.0.9)

Вы можете просто развернуть tar-архив rsbac-x.y.z.tar.gz в вашем основном каталоге ядра. При этом ни один из существующих файлов не будет изменен, но будут добавлены несколько новых. Документация на RSBAC находится в Documentation/rsbac/.

Для связи ядра с этими файлами оно должно быть соответствующим образом модифицировано. До версии 1.0.9а патчи находились в каталоге rsbac/, по одному для каждой поддерживаемой версии ядра. С 1.0.9b и по сегодняшний день патчи размещаются отдельно от базового terball-а в связи с тем, что на сегодняшний день их стало слишком много. Приложите патч с названием gzip -dc patch-x.y.z.gz | patch -p1 SPMamp;>perr в основном каталоге ядра. В perr вы найдете протокол, в нем не должно быть отклонений. Если вы применяете патч к версии ядра, отличной от той на которую расчитан этот патч (что не рекомендуется), изучите сначала Documentation/rsbac/README-patching.

Затем, для зависимостей версии файла, вы должны вызвать команду 'touch Makefile', для получения новых значений версий с использованием '-rsbac'.

В том случае, если ваше ядро уже содержит патч от старой версии RSBAC, будет достаточно развернуть tarball и выполнить компиляцию заново, так как патч универсален настолько, насколько это возможно. Если это будет изменено, то вы найдете в Documentation/rsbac/INSTALL предупреждение об этом.

Обратите внимание. Изменения были в патчах для следующих версий:


next up previous
Next: Конфигурация и Сборка Ядра Up: Установка Previous: а) Приложение большого патча
next up previous
Next: Первая Загрузка Up: Установка Previous: b) Установка из tarball

Конфигурация и Сборка Ядра

Внимание: От версии к версии RSBAC атрибуты бинарных файлов, представленных на диске, могут меняться даже без пересборки с различными настройками. Перед загрузкой с обновленным ядром при помощи средств администрирования вы должны сделать резервные копии! Смотрите об этом здесь [*]. Однако с патча версии 1.0.6 уже имеется автоматическое обновление этих списков, но отсутствует возможность раздельного их восстановления. Внимание: Между версиями 1.0.8а и 1.0.9 определение ролей RC-модели не может быть автоматически обновлено.

Конфигурирование ядра, как и в обычном случае, начинается вызовом make menuconfig в главном каталоге с исходными текстами. В главном меню появится новое подменю, называемое Rule Set Based Access Control, в котором слишком много вариантов выбора, чтобы писать о них здесь. Детальное описание смотрите в справочной информации по конфигурации.

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

С версиями RSBAC до 1.0.9b, перед перезагрузкой, вы должны установить средства администрации, особенно файл useraci, который должен находится в /rsbac (см.ниже), иначе ваша система не загрузится. С версии 1.0.9b это присутствует в стандартной автоматической установке, если пользовательские установки не читаемы.

Дополнительно вам необходимо создать две пользовательских записи, первая это офицер безопасности /администратор RC-роли/ ACL Supervisor с ID пользователя равным 400 и, если вы намерены использовать модуль PM, офицера защиты данных с пользовательским ID 401. Позже они могут быть изменены. Они нужны вам для администрирования, так как одного root будет уже недостаточно. Если вы действительно меняете значения по умолчанию для этих цифр, то измените пожалуйста макросы RSBAC_SECOFF_UID и RSBAC_DATAPROT_UID в include/rsbac/types.h.

Role Protection запрещает процессам с ID 0 производить смену на офицера безопасности. Вход офицера безопасности или офицера защиты данных происходит путем регистрации в системе обычного пользователя с последующим su. Если AUTH-модель и Role Protection задействованы обе одновременно, вы вряд ли будете способны получить доступ к вашей системе вообще. В большинстве случаев лучше использовать AUTH вместо Role Protection. По этой причине Role Protection в версии 1.1.1 отмечена как 'нежелательная' и позднее может быть удалена.


next up previous
Next: Первая Загрузка Up: Установка Previous: b) Установка из tarball
next up previous
Next: Вероятные Проблемы/Maintenance Mode Up: Установка Previous: Конфигурация и Сборка Ядра

Первая Загрузка

При первой загрузке вашего нового RSBAC ядра с AUTH-моделью не забудьте передать ядру параметр rsbac_auth_enable_login, например в приглашении lilo:

rsbac rsbac_auth_enable_login
Если вы забудете про это, то вы не сможете войти в систему (зайти сможет только root) и вам придется перезагрузиться при помощи CTRL-ALT-DEL.

В процессе загрузки вы увидете некоторые сообщения RSBAC от rsbac_init()-подобных. Также будут встречаться ошибки подобные 'xyz could not be read, error RSBAC_ENOTFOUND'. Эти (теперь уже) безвредные ошибки указывают на то, что просто нет никаких Access Control Information (ACI) файлов, так как вы еще не установили никаких атрибутов. Они необходимы в случае, если список атрибутов потерялся из-за некоторого отказа системы, для уведомления об этом администратора при перезагрузке. Некоторые списки создаются сами, для обеспечения работоспособности системы, но они не будут сохранены, пока вы сами не внесете в них изменения.

Если вы включили AUTH в список выбранных вами моделей, некоторые серверные процессы попробуют установить setuid и получат отказ. Это демонстрирует, что AUTH прекрасно функционирует: у них нет права на установку setuid без допуска. Одной из ваших первых административных задач является установка требуемой AUTH-совместимости для серверных процессов, например с rsbac_fd_menu. Для этого достаточно зарегистрироваться в системе как пользователь 400 (с.а.), вызвать rsbac_fd_menu <имя-исполняемого-файла-серверного-процесса> и вы сможете задать через меню пункты AUTH-совместимости. Необходимые ID пользователя можно найти в журнале регистрации событий системы, ищите запросы на CHANGE_OWNER которые NOT_GRANTED и используйте значения их атрибутов.


next up previous
Next: Вероятные Проблемы/Maintenance Mode Up: Установка Previous: Конфигурация и Сборка Ядра
next up previous
Next: Обновление RSBAC Up: Установка Previous: Первая Загрузка

Вероятные Проблемы/Maintenance Mode

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

С v1.1.1 введен параметр 'Soft Mode', который позволит вам отключить проверку доступа во время работы без перезагрузки системы. Пожалуйста, пользуйтесь этой функцией с чрезвычайной осторожностью, так как это может привести к возникновению огромных дыр в защите!

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

В версиях RSBAC до 1.0.9а, если при загрузке вы получаете сообщения rsbac_init(): User ACI could not be read и система не загружается, значит стандартный useraci-файл не годится для вашей системы. Это обычно случается на не-i386 системах. В таком случае вы должны загрузить систему с ремонтным ядром RSBAC (см.ниже). Затем вы можете настроить роли и т.п. как обычный пользователь, например используя сценарий оболочки user_aci.sh из каталога инструментария администратора. Если что-то все еще не работает, то обратитесь за поддержкой в лист рассылки RSBAC (http://www.rsbac.org/contact.htm) или лист рассылки дистрибутива Castle (http://www.altlinux.ru/mailman/listinfo/castle).

В RSBAC версии 1.1.0 имеется ошибка в установках по умолчанию для ACL-модели, препятствующие выполнению некоторых файлов. Пожалуйста убедитесь, что вы приложили исправление для нее (http://www.rsbac.org/bugfixes/).

Если задействован AUTH-модуль, то вы не сможете зарегистрироваться в системе пока программа регистрации пользователей в системе не имеет достаточных прав для смены признака владельца процесса (setuid). Вы можете загрузить систему передав ядру параметр rsbac_auth_enable_login для предоставления полного setuid-допуска для /bin/login. Как только будет установлена и сконфигурирована правильная аутентификация вы сможете это отключить.

Также, при задействованном AUTH, некоторые серверные процессы могут функционировать не так как надо, так как получение setuid для них запрещено. В этом случае офицер безопасности (secoff, id 400) должен назначить программе серверного процесса AUTH-совместимость для целевого пользователя. Вы с легкостью обнаружите такие случаи в журнале регистрации событий системы: CHANGE_OWNER-запрос идентификатора серверного процесса, признак владельца, attr_val xyz будут возвращать NOT_GRANTED. Возьмите uid xyz и установите совместимость при помощи rsbac_fd_menu имя_файла.


next up previous
Next: Обновление RSBAC Up: Установка Previous: Первая Загрузка
next up previous
Next: Параметры Ядра Up: Установка Previous: Вероятные Проблемы/Maintenance Mode

Обновление RSBAC

Если вы обновили свое ядро и структура данных для списка типов изменилась, то будет выведено предупредительное сообщение. Данные от старой версии будут конвертированы и загрузка пройдет как обычно. Однако, данные от очень старых версий или в поврежденных файлах могут быть не читаемы, тогда устройство или список получит статус no_write. Статус no_write может быть отключен только через proc-интерфейс (смотрите Documentation/rsbac/README-proc). Наилучший способ - это создание [*] всех атрибутов перед первой загрузкой.

Если в новых версиях вы выберете дополнительные модели, то вы должны привести атрибуты модели в соответствие с ремонтным ядром, например признак пользователя rc_def_role для пользователей 0 и 400. Необходимые значения можно найти в user_aci.sh, в инструментарии администратора, или на странице [*]. Это также должно быть сделано с (дополнительным) перехватом sys_read/write (с v1.1.1.), пока не начали беспокоить запросы READ и WRITE к файлам и fifo-объектам.

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


next up previous
Next: Параметры Ядра Up: Установка Previous: Вероятные Проблемы/Maintenance Mode
next up previous
Next: Установка и Администрирование

Rule Set Based Access Control (RSBAC) для Linux - Установка и Администрирование




next up previous
Next: Установка и Администрирование

Rule Set Based Access Control (RSBAC) для Linux - Регистрация Событий


Система Регистрации Событий

Access Control Decision Facility (ADF) содержит мощную систему регистрации событий. Имеется возможность указать события, которые будут зарегистрированы в зависимости от типа запроса, пользователя, выполняемого и целевого объекта (файла, FIFO, каталога или устройства). Некоторые из этих особенностей должны быть задействованы в конфигурации ядра.

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

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

Протоколирование по запросу устанавливается средствами командной строки switch_adf_log, текущие значения могут быть просмотрены в /proc/rsbac-info/adf_loglevel. Настройки индивидуального протоколирования реализованы как атрибуты и могут быть установлены при помощи обычных средств.

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

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

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

2. Если задействовано индивидуальное протоколирование программы и уровнем регистрации программы для запроса является

3. Если задействовано индивидуальное протоколирование объекта, объект является файлом, FIFO, каталогом или устройством и уровнем регистрации объекта для запроса является

4. Если уровнем регистрации для запроса является

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


Перевод: Александр Блохин <sass@uustoll.ee>


Rule Set Based Access Control (RSBAC) для Linux - Регистрация Событий


Система Регистрации Событий

Access Control Decision Facility (ADF) содержит мощную систему регистрации событий. Имеется возможность указать события, которые будут зарегистрированы в зависимости от типа запроса, пользователя, выполняемого и целевого объекта (файла, FIFO, каталога или устройства). Некоторые из этих особенностей должны быть задействованы в конфигурации ядра.

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

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

Протоколирование по запросу устанавливается средствами командной строки switch_adf_log, текущие значения могут быть просмотрены в /proc/rsbac-info/adf_loglevel. Настройки индивидуального протоколирования реализованы как атрибуты и могут быть установлены при помощи обычных средств.

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

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

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

2. Если задействовано индивидуальное протоколирование программы и уровнем регистрации программы для запроса является

3. Если задействовано индивидуальное протоколирование объекта, объект является файлом, FIFO, каталогом или устройством и уровнем регистрации объекта для запроса является

4. Если уровнем регистрации для запроса является

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


Перевод: Александр Блохин <sass@uustoll.ee>


next up previous
Next: Модели RSBAC

Rule Set Based Access Control (RSBAC) для Linux - Модели




next up previous
Next: Модели RSBAC
next up previous
Next: Mandatory Access Control (MAC) Up: Rule Set Based Access Previous: Rule Set Based Access

Модели RSBAC

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



next up previous
Next: Mandatory Access Control (MAC) Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Состояния Запроса для доступа Up: Mandatory Access Control (MAC) Previous: Определение

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 определяет четыре модели доступа:

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

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



Subsections
next up previous
Next: Состояния Запроса для доступа Up: Mandatory Access Control (MAC) Previous: Определение
next up previous
Next: Реализация RSBAC MAC Up: Unix System V/MLS Previous: Unix System V/MLS

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

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 объект каталога и >= и = стоит для обозначения доминирует и имеет тот-же уровень. Запись и чтение на каталогах подразумевает доступ к объектам без возможности их открытия.


next up previous
Next: Реализация RSBAC MAC Up: Unix System V/MLS Previous: Unix System V/MLS
next up previous
Next: RSBAC MAC-Light Up: Mandatory Access Control (MAC) Previous: Состояния Запроса для доступа

Реализация 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.



Subsections
next up previous
Next: RSBAC MAC-Light Up: Mandatory Access Control (MAC) Previous: Состояния Запроса для доступа
next up previous
Next: Модель целостности Кларка - Up: Реализация RSBAC MAC Previous: Реализация RSBAC MAC

RSBAC MAC-Light

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

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


next up previous
Next: Модель целостности Кларка - Up: Реализация RSBAC MAC Previous: Реализация RSBAC MAC
next up previous
Next: Functional Control (FC) Up: Mandatory Access Control (MAC) Previous: RSBAC MAC-Light

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

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


next up previous
Next: Functional Control (FC) Up: Mandatory Access Control (MAC) Previous: RSBAC MAC-Light
next up previous
Next: Security Information Modification (SIM) Up: Модели RSBAC Previous: Модель целостности Кларка -


Functional Control (FC)

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

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

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

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

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


next up previous
Next: Security Information Modification (SIM) Up: Модели RSBAC Previous: Модель целостности Кларка -
next up previous
Next: Simone Fischer-Hubner's Privacy Model Up: Модели RSBAC Previous: Functional Control (FC)


Security Information Modification (SIM)

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

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

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

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


next up previous
Next: Simone Fischer-Hubner's Privacy Model Up: Модели RSBAC Previous: Functional Control (FC)
next up previous
Next: Malware Scan (MS) Up: Модели RSBAC Previous: Security Information Modification (SIM)


Simone Fischer-Hubner's Privacy Model (PM)

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

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

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

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

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


next up previous
Next: Malware Scan (MS) Up: Модели RSBAC Previous: Security Information Modification (SIM)
next up previous
Next: File Flags (FF) Up: Модели RSBAC Previous: Simone Fischer-Hubner's Privacy Model


Malware Scan (MS)

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

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

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

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


next up previous
Next: File Flags (FF) Up: Модели RSBAC Previous: Simone Fischer-Hubner's Privacy Model
next up previous
Next: Role Compatibility (RC) - Up: Модели RSBAC Previous: Malware Scan (MS)


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 не может быть перемещен или замещен для подделки других домашних каталогов для большинства пользователей.


next up previous
Next: Role Compatibility (RC) - Up: Модели RSBAC Previous: Malware Scan (MS)
next up previous
Next: Модель Белла и Ла-Падулы Up: Модели RSBAC Previous: Модели RSBAC


Mandatory Access Control (MAC)



next up previous
Next: Модель Белла и Ла-Падулы Up: Модели RSBAC Previous: Модели RSBAC
next up previous
Next: Роли и Типы Up: Модели RSBAC Previous: File Flags (FF)

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

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

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

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



next up previous
Next: Роли и Типы Up: Модели RSBAC Previous: File Flags (FF)
next up previous
Next: Атрибуты RC Up: Role Compatibility (RC) - Previous: Role Compatibility (RC) -

Роли и Типы

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



Поле Вхождения Роли Типы/Значения Описание
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.


next up previous
Next: Атрибуты RC Up: Role Compatibility (RC) - Previous: Role Compatibility (RC) -
next up previous
Next: Специальные Значения Up: Role Compatibility (RC) - Previous: Роли и Типы

Атрибуты RC

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

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

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

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


next up previous
Next: Специальные Значения Up: Role Compatibility (RC) - Previous: Роли и Типы
next up previous
Next: Начальная Конфигурация Up: Role Compatibility (RC) - Previous: Атрибуты RC

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

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

Специальное Значение Роли Значение
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 новой роли




next up previous
Next: Начальная Конфигурация Up: Role Compatibility (RC) - Previous: Атрибуты RC
next up previous
Next: Role Compatibility (RC) - Up: Role Compatibility (RC) - Previous: Специальные Значения

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

Если запущено без определений ролей, то устанавливаются три предопределенных роли: 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 чтобы их копировать.


next up previous
Next: Role Compatibility (RC) - Up: Role Compatibility (RC) - Previous: Специальные Значения
next up previous
Next: Вхождения Роли и Типа Up: Модели RSBAC Previous: Начальная Конфигурация


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 [*].



next up previous
Next: Вхождения Роли и Типа Up: Модели RSBAC Previous: Начальная Конфигурация
next up previous
Next: Атрибуты RC Up: Role Compatibility (RC) - Previous: Role Compatibility (RC) -

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

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



Поле Вхождения Роли Тип/Значение Описание
имя строка из 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.


next up previous
Next: Атрибуты RC Up: Role Compatibility (RC) - Previous: Role Compatibility (RC) -
next up previous
Next: Специальные Значения Up: Role Compatibility (RC) - Previous: Вхождения Роли и Типа

Атрибуты 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.


next up previous
Next: Специальные Значения Up: Role Compatibility (RC) - Previous: Вхождения Роли и Типа
next up previous
Next: Начальная Конфигурация Up: Role Compatibility (RC) - Previous: Атрибуты RC

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

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



Специальное Значение Роли Предназначение
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 новой роли




next up previous
Next: Начальная Конфигурация Up: Role Compatibility (RC) - Previous: Атрибуты RC
next up previous
Next: Authentification Module (AUTH) Up: Role Compatibility (RC) - Previous: Специальные Значения

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

Если запущено без определений роли, устанавливаются три предопределенных роли: 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 содержат сложную модель разделения обязанностей. Для этого были сделаны следующие дополнения:

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

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

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

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

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

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

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

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


next up previous
Next: Authentification Module (AUTH) Up: Role Compatibility (RC) - Previous: Специальные Значения
next up previous
Next: Определения. Up: Mandatory Access Control (MAC) Previous: Mandatory Access Control (MAC)

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



next up previous
Next: Определения. Up: Mandatory Access Control (MAC) Previous: Mandatory Access Control (MAC)
next up previous
Next: Основы Up: Модели RSBAC Previous: Начальная Конфигурация


Authentification Module (AUTH)



next up previous
Next: Основы Up: Модели RSBAC Previous: Начальная Конфигурация
next up previous
Next: Атрибуты AUTH Up: Authentification Module (AUTH) Previous: 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 которые вы разрешите.


next up previous
Next: Атрибуты AUTH Up: Authentification Module (AUTH) Previous: Authentification Module (AUTH)
next up previous
Next: Специальные Значения Up: Authentification Module (AUTH) Previous: Основы

Атрибуты AUTH

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

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

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


next up previous
Next: Специальные Значения Up: Authentification Module (AUTH) Previous: Основы
next up previous
Next: Начальная Конфигурация Up: Authentification Module (AUTH) Previous: Атрибуты AUTH

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

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


next up previous
Next: Начальная Конфигурация Up: Authentification Module (AUTH) Previous: Атрибуты AUTH
next up previous
Next: Администрирование Up: Authentification Module (AUTH) Previous: Специальные Значения

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

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

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


next up previous
Next: Администрирование Up: Authentification Module (AUTH) Previous: Специальные Значения
next up previous
Next: Access Control Lists Module Up: Authentification Module (AUTH) Previous: Начальная Конфигурация

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

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

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

Администрирование в основном основано на атрибутах файла и процесса и наборах возможностей обозначенных выше. Детали смотри в Руководстве по Установке и Администрированию [*].


next up previous
Next: Access Control Lists Module Up: Authentification Module (AUTH) Previous: Начальная Конфигурация
next up previous
Next: Основы Up: Модели RSBAC Previous: Администрирование


Access Control Lists Module (ACL)



next up previous
Next: Основы Up: Модели RSBAC Previous: Администрирование
next up previous
Next: Об Этом Документе Up: Access Control Lists Module Previous: Access Control Lists Module

Основы

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

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

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

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

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

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

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

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

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

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


next up previous
Next: Об Этом Документе Up: Access Control Lists Module Previous: Access Control Lists Module
next up previous
Up: Модели RSBAC Previous: Основы

Об Этом Документе

Составитель:

Перевод:


next up previous
Up: Модели RSBAC Previous: Основы
next up previous
Next: Состояния Системы Up: Модель Белла и Ла-Падулы Previous: Модель Белла и Ла-Падулы

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

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

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


next up previous
Next: Состояния Системы Up: Модель Белла и Ла-Падулы Previous: Модель Белла и Ла-Падулы
next up previous
Next: Свойства Защиты Up: Модель Белла и Ла-Падулы Previous: Определения.

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

Каждое обращение субъекта 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.


next up previous
Next: Свойства Защиты Up: Модель Белла и Ла-Падулы Previous: Определения.
next up previous
Next: Правила Принятия Решений Up: Модель Белла и Ла-Падулы Previous: Состояния Системы

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

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


bellmalf.gif (2333 Byte)

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

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

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

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

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


next up previous
Next: Правила Принятия Решений Up: Модель Белла и Ла-Падулы Previous: Состояния Системы
next up previous
Next: Функции Up: Модель Белла и Ла-Падулы Previous: Свойства Защиты

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

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

Текущий допуск (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


next up previous
Next: Функции Up: Модель Белла и Ла-Падулы Previous: Свойства Защиты
next up previous
Next: Определение Up: Модель Белла и Ла-Падулы Previous: Правила Принятия Решений

Функции

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

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

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

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

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

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

change-object-level()

change-current-level()

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

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


next up previous
Next: Определение Up: Модель Белла и Ла-Падулы Previous: Правила Принятия Решений
next up previous
Next: Unix System V/MLS Up: Модель Белла и Ла-Падулы Previous: Функции

Определение

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

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

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


next up previous
Next: Unix System V/MLS Up: Модель Белла и Ла-Падулы Previous: Функции
next up previous
Next: Модели RSBAC

Rule Set Based Access Control (RSBAC) для Linux - Модели




next up previous
Next: Модели RSBAC
next up previous
Next: Введение

От Формальной Модели Приватности к Её Реализации

Резюме

Технологии приватности в последнее время становятся всё более и более актуальны, так как индивидуальная секретность в Глобальном Информационном Сообществе подвержена опасности. В этом документе описывается обновлённая версия формальной модели приватности, которая может быть использована для технического внедрения законодательных требований секретности. Этот документ демонстрирует, как может быть определена и реализована политика приватности в соответствии с Generalized Framework for Access Control (GFAC).




next up previous
Next: Введение
next up previous
Next: Формальная Модель Секретности Up: От Формальной Модели Приватности Previous: От Формальной Модели Приватности

Введение

При продвижении к Глобальному Информационному Сообществу, индивидуальная секретность подвергается риску (см. [Fischer-Hubner 1997г]). Директива ЕС по защите информации, также как и законы о секретности многих западных государств требует, чтобы при сборе или обработке персональной информации гарантировались основные принципы секретности, типа:

Секретность, в Глобальном Информационном Сообществе, не может быть эффективно осуществлена исключительно законодательными средствами. Поэтому члены комиссии по защите данных требуют критерии дизайна для информационных систем и технически предписанных юридических требований приватности. Последнее исследование Dutch Data Protection Authority и The Information and Privacy Commissioner for the Province of Ontario / Canada [Registratiekamer et al. 1995] рассматривает технологии расширения секретности, которые обеспечивают пользователю анонимность или псевдонимность. Privacy Class of the Common Criteria [Common Criteria 1998] также ориентирован на анонимность, псевдонимность, не связность и не поднадзорность пользователей.

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

Небезызвестная модель Bell - LaPadula предназначена для защиты секретной информации. Её политика Mandatory Access Control (MAC) ограничивает доступ к объектам, основываясь на важности содержащейся в объектах информации и благонадёжности субъектов. Между тем, личные данные не могут быть точно классифицированы, в зависимости от их важности, потому, что важность личных данных зависит от цели и контекста их использования. Для внедрения секретности должна осуществляться проверка, соответствует ли цель задания, выполняемого пользователем желающем получить личные данные, целям, для которых были получены эти личные данные (необходимость взаимосвязанности целей).

Discretionary Access Control (DAC) ограничивает доступ к объектам основываясь на тождестве субъектов и/или групп субъекта. DAC допускает предоставление и отмену доступа к данным, оставляя это на усмотрение пользователя с правами доступа, предоставляющими контроль над данными. Однако, в аспекте секретности, личные данные субъектов данных не должны "принадлежать" или "контролироваться" другим человеком. Для защиты секретности, решение контроля доступа должно быть определено не идентификатором пользователя, а задачей, которую индивидуальный пользователь в настоящее время выполняет. Личные данные должны быть доступны пользователю только тогда, когда доступ необходим для выполнения его/её текущего задания и если он/она авторизован для выполнения этого задания (неизбежная необходимость для обработки данных).

Более новые модели защиты, такие как модель Кларка-Уилсона [Clark/Wilson 1987] или модели Role-based Access Control (например, [Ferraiolo/Kuhn 1992]) могут назначать требования и аспекты защиты (например, целостность пользовательских данных, предоставление пользователям/ролям только тех права доступа, что необходимы для выполнения их обязанностей), которые больше подходят для защиты секретности личных данных. Однако, они не предназначены для непосредственного назначения таких принципов секретности, как взаимосвязанность целей.

В этом документе, обновлённая и дополненная версия формальной, задаче-ориентированной модели секретности, которая была представлена в [Fischer-Hubner 1994], [Fischer-Hubner 1995], должна быть представлена как вероятно используемая в целях технического предписания законных требований секретности в системе, тем самым демонстрируя реализацию политики секретности с другими политиками защиты в соответствии с Generalized Framework for Access Control (GFAC, см. [Abrams et al 1990], [LaPadula 1995]).


next up previous
Next: Формальная Модель Секретности Up: От Формальной Модели Приватности Previous: От Формальной Модели Приватности
next up previous
Next: Модуль ACI Up: Спецификация и Реализация в Previous: Архитектура GFAC

Средство Управления Доступом (AEF)

Так как всем уместным, с точки зрения безопасности, обращениям в системах Unix требуются системные вызовы к ядру, AEF реализуется дополнением всех уместных системных вызовов ADF-запросами и сообщениями уведомляющего характера. Для каждого системного вызова используется один ADF-запрос, обращенный к его функциональности, который, при необходимости, может быть повторён. Например, открытый системный вызов должен быть дополнен ADF-запросом для получения доступа на чтение к каталогу, созданию каталога/файла, усечения файла и для дополнения-/чтения-/записи/чтения-записи-открытия файла.

Каждое состояние функции перехода в модели секретности вызвано системным вызовом. Поэтому AEF был дополнен системными вызовами (change-current-task, create-personal-data, точно так же, как и все привилегированные системные вызовы для добавления или удаления ACI), которые необходимы только для модели секретности.


next up previous
Next: Модуль ACI Up: Спецификация и Реализация в Previous: Архитектура GFAC
next up previous
Next: Средство Принятия Решения о Up: Спецификация и Реализация в Previous: Средство Управления Доступом (AEF)

Модуль ACI

Администрирование ACI и ADF осуществлено в виде независимых модулей. Модуль ACI отвечает за надежное администрирование атрибутов защиты процессов (process-ACI), пользователей (user-ACI) и всех необходимых ресурсов, находящихся под управлением политики безопасности (object-ACI). Кроме того, этот модуль осуществляет администрирование информации управления доступом, такой как список требуемых допусков для определенных задач и их атрибутов безопасности (в отличие от [Abrams et al. 1990] мы не делаем разницы между ассоциированным с субъектами или объектами ACI и информацией ACC (Access Control Context), которая является дополнительной информацией управления доступом (используемой в принятии решения управления доступом). Доступ к ACI возможен только для вызовов определённых функций. Формат хранения ACI пользователя и файла независим от используемой файловой системы.

В приведённой ниже таблице перечислена информация управления доступом, необходимая для спецификации и реализации системой политики секретности, соответствующие переменные модели секретности и области их значения. Жирным текстом выделены предустановленные значения. ID это аббревиатура идентификатора. Модуль ACI, соответствующий состояниям переменных модели секретности, может быть описан при помощи их соответствующих состояний переменных. Остальные атрибуты и структуры данных ACI описаны ниже.


Значения переменной User модели ACI  
authorised-tasks AT список task-ID задач, включая NIL
role sec-officer, user, data-protection-officer, tp-manager, system-admin


Значения переменной Process модели ACI  
owner (указатель на пользователя)
transformation procedure CTP transformation-procedure-ID или NIL
current_task CT task-ID , или NIL
process-type NIL, TP
Input-Purposes список purpose-ID


Каждый процесс Unix указывает на пользователя, который является его владельцем. Типом процесс, выполняющего процедуру преобразования, является TP. Все остальные являются процессами NIL-типа.


Значения переменной Object модели ACI  
class object-class-ID или none
transformation-procedure TRANS transformation-procedure-ID или NIL
object-type file, dir, ipc, scd
data-type NIL, TP, личные данные, не личные данные


Значениями object-type, определенными для спецификации политики секретности, являются file, dir (каталог), ipc и scd. file и dir имеют очевидные значения в Unix, ipc означает "межпроцессное взаимодействие" (например, очередь сообщений, разделяемая память в Unix System V, доменные подключения в BSD Unix). scd означает "данные контроля системы" (например, системное время). personal-data является типом данных файла, содержащего личные данные. Тип данных файла, содержащего не личные данные, обозначен как non-rersonal-data. TP обозначает тип данных содержащих выполняемый код (разрешенной) процедуры преобразования. Все остальные файлы (например, остальные выполняемые программы) имеют тип данных NIL.


Значения переменной Object-class модели ACI  
purposes O-Purposes список purpose-ID


Дополнительный список переменных модели ACI форма вхождения
список Necessary-Accesses NA (task-ID, class-ID, transformation-procedure-ID, access-right)
список Consent C (purpose-ID, object-ID)
список Purpose P список purpose-IDs
список Task T список task-ID
записи Ticket TKT (ticket-ID, issuer, function-type, parameter-list, timestamp)
список O-Class список o-class-ID


Значения переменной Task модели ACI  
цель T-Purpose purpose-ID
authorised-TP ATP список, включающий transformation-procedure-ID
responsible список user-ID ответственных


Значения Ticket-ACI  
ticket-issuer user-ID
function-type add_authorised_tasks, delete_authorised_tasks, add_task, delete_task, add_NA, delete_NA, add_purpose, delete_purpose, add_object-class, delete_object_class, add_authorised-TP, delete_authorised_TP, add_consent, delete_consent, add_responsible_user, delete_responsible_user, set-role, set-object-class
parameter-list в зависимости от function-type
timestamp системное время


next up previous
Next: Средство Принятия Решения о Up: Спецификация и Реализация в Previous: Средство Управления Доступом (AEF)
next up previous
Next: Заключение Up: Спецификация и Реализация в Previous: Модуль ACI

Средство Принятия Решения о Предоставлении Доступа (ADF)

Модуль ADF приняв запрос о предоставлении доступа от AEF оценивает его при помощи правил различных политик безопасности. Схема 4, например, демонстрирует правила политики секретности ADF для запросов типа append-open. Язык спецификации должен быть интуитивно понятен для широкой аудитории, а так же его описание имеется в [LaPadula 1995]. В этой спецификации следующие предикаты соответствуют следующим значениям:

Necessary (task, class, transp, right) <=> (task, class, transp, right) is element of the table Necessary-Accesses.

Purpose-binding(task, class) <=> Purpose(task) is element of Purposes(class).

Consent(task, object) <=> (purpose(task), object) is element of the table consent.

CASE APPEND_OPEN

   SELECT CASE target[input-argument]

      CASE file

         SELECT CASE data-type(object)

            CASE personal-data

                  IF [Necessary (current-task (process), class (object),

                       transformation-procedure (process), append )

               AND

                  Purpose-binding (current-task (process), class (object)) 

               OR 

                  consent (current-task (process), object)]

               AND

                  purposes(class(object)) in input-purposes(process)

               THEN

                  return(YES)

               ELSE

                  return(NO)

            CASE TP (* it is not allowed to directly modify TPs *)

               return (NO)

            CASE non-personal-data

                  IF purposes(class(object)) in input-purposes(process) 

               THEN (* in this case input-purposes(process) is equal

                     to the set of all possible purposes *) return(YES)

               ELSE return(NO)

            CASE ELSE

               return(NO);

            CASE ipc

                  IF class(object) is none (*object contains non-personal-data*) 

               THEN

                  IF purposes(class(object)) in input-purposes(process) 

               THEN

                  return(YES)

               ELSE

                  return(NO)

               ELSE (* object contains personal data *)

                  IF Necessary (current-task(process), class(object),

                     transformation-procedure (process), append)

               AND

                  Purpose-binding (current-task (process), class(object))

               AND

                  purposes(class(object)) in input-purposes(process)

               THEN (* consents are not defined for ipc-objects *)

                  return (YES)

               ELSE

                  return (NO)

            CASE ELSE

               return (UNDEFINED);

Схема 4: Спецификация ADF - правила политики секретности для запроса типа append-open

Для соответствия с моделью секретности файлы личных данных могут быть созданы при помощи системного вызова create_personal_data, если как параметр указан класс нового файла. Для сохранения функциональности в системе Unix, процессам TP-типа должно быть позволено создание объектов при помощи обычного системного вызова Unix - creat (создать). Если процесс TP-типа создает файл или ipc-объект, то эти объекты должны обрабатываться как личные данные, во-избежание возникновения нелегального информационного потока. Между тем, если был вызван системный вызов creat, то в качестве параметра для нового файла или ipc-объекта не может быть использован класс объекта. Следовательно, для каждой цели pj уникальным значением default-class будет являться: purpose(default-class(pj)) = pj.

Если процесс TP-типа создаёт при помощи системного вызова creat файл или объект ipc-типа, то object-class вновь созданного объекта будет иметь значение default-class цели текущей задачи процесса.


next up previous
Next: Заключение Up: Спецификация и Реализация в Previous: Модуль ACI
next up previous
Next: Об Этом Документе Up: От Формальной Модели Приватности Previous: Средство Принятия Решения о

Заключение

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

Литература:

[Abrams et al. 1990] Marshall Abrams, K.Eggers, L.LaPadula, I.Olson, "A Generalized Framework for Access Control: An Informal Description", Proceedings of the 13th National Computer Security Conference, Washington, October 1990.

[Clark/ Wilson 1987] David Clark, David Wilson, "A Comparison of Commercial and Military Computer Security Policies", Proceedings of the IEEE Computer Society Symposium on Security and Privacy, Oakland, 1987.

[Common Criteria 1998] Common Criteria Editorial Board: Common Criteria for Information Technology Security Evaluation, Version 2.0, May 1998.

[Ferraiolo/Kuhn 1992] David Ferraiolo, Richard Kuhn, "Role-Based Access Controls", Proceedings of the 15th National Computer Security Conference, Baltimore MD, October 1992.

[Fischer-Hu"bner 1994] Simone Fischer-Hu"bner, "Towards a Privacy-Friendly Design and Usage of IT-Security Mechanisms", Proceedings of the 17th National Computer Security Conference, Baltimore MD, October 1994.

[Fischer-Hu"bner 1995] Simone Fischer-Hu"bner, "Considering Privacy as a Security-Aspect: A Formal Privacy-Model", DASY-Papers No. 5/95, Institute of Computer and System Sciences, Copenhagen Business School, 1995.

[Fischer-Hu"bner 1997a] Simone Fischer-Hu"bner, "Privacy at Risk in the Global Information Society", in: Jacques Berleur and Diane Whitehouse, Eds., 'An ethical global information society: Culture and democracy revisited', Proceedings of the IFIP-WG9.2/9.5 Corfu International Conference, May 8-10, 1997, Chapman &Hall, 1997.

[Fischer-Hu"bner 1997b] Simone Fischer-Hu"bner, "A Formal Task-based Privacy Model and its Implementation: An updated Report", Proceedings of the Second Nordic Workshop on Secure Computer Systems NORDSEC'97, Helsiniki, November 6-7, 1997.

[LaPadula 1995] Leonard LaPadula, "Rule-Set Modelling of Trusted Computer System", Essay 9 in: M.Abrams, S.Jajodia, H. Podell, "Information Security - An integrated Collection of Essays", IEEE Computer Society Press, 1995.

[Ott 1997] Amon Ott, "Regel-basierte Zugriffskontrolle nach dem Generalized Framework for Access Control-Ansatz am Beispiel Linux", Universita"t Hamburg, Fachbereich Informatik,

http://agn-www.informatik.uni-hamburg.de/people/1ott/rsbac/eng.htm (08/May/2000: New location at http://www.rsbac.org).

[Registratiekamer et al. 1995] Registratiekamer, The Netherlands & Information and Privacy Commissioner /Ontario, Canada: "Privacy-Enhancing Technologies: The Path to Anonymity", Vol.1, August 1995.

[Sobirey et al. 1997] Michael Sobirey, Simone Fischer-Hu"bner, Kai Rannenberg, "Pseudonymous Auditing for a Privacy-Enhanced Intrusion Detection", Proceedings of the IFIP TC-11 Sec'97-Conference "Information Security in Research and Business", Copenhagen, May 14-16, Eds: L.Yngstroem, J.Carlsen, Capman&Hall, 1997.


next up previous
Next: Об Этом Документе Up: От Формальной Модели Приватности Previous: Средство Принятия Решения о
next up previous
Up: От Формальной Модели Приватности Previous: Заключение

Об Этом Документе

Составители:

Перевод:


next up previous
Up: От Формальной Модели Приватности Previous: Заключение
next up previous
Next: Переменные состояния Up: От Формальной Модели Приватности Previous: Введение

Формальная Модель Секретности

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

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

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


next up previous
Next: Переменные состояния Up: От Формальной Модели Приватности Previous: Введение
next up previous
Next: Инварианты Up: Формальная Модель Секретности Previous: Формальная Модель Секретности

Переменные состояния

В модели секретности определены следующие защищённые (или лучше: секретные) состояния:

Субъекты S: Субъекты являются активными объектами системы (например, процессы).

Активный субъект: тождество субъекта, активного в настоящий момент и вызывающего функции перехода.

Объект O: Объекты являются пассивными составляющими системы (например, файлы, записи).

Объекты личных данных OP м O: Объектами личных данных являются объекты, содержащие информацию личного характера. Личными данными являются данные об идентифицированном или идентифицируемом человеке.

Объектные классы O-class: Объекты содержащие личную информацию могут быть выражены как классы, например, данные о пациенте в больнице, данные счёта. O-class = набор разнообразных объектных классов = {o-class1, o-class2, none...}.

Класс не персональных данных имеет предопределенное значение "none".

Функция объектного класса Class: Каждый объект классифицирован по объектному классу. Функция Class определена следующим образом: O -> O-class, где Class(Oj) является объектным классом объекта Oj.

"Ojн O \ OP: Class(Oj) = none.

Задачи T: Доступ субъектов к объектам должен быть разрешён только посредством выполнения задач. Для каждого приложения должны быть определены задачи.

Текущая Задача CT: Задачи, выполняемые субъектом в настоящий момент, называются текущими задачами. Если субъект в настоящий момент не выполняет какой-либо задачи, то значением его текущей задачи является Nil. Функция CT выражена следующим образом: S -> T х {Nil}, где CT(Si) является текущей задачей субъекта Si.

Авторизованные Задачи AT: AT это функция, определяющая не пустой набор задач для субъекта, для выполнения которых этот субъект авторизован. AT: S -> 2 Tх {Nil} \ ф, где AT(Si) является набором задач, для выполнения которых авторизован Si. " Si н S: Nil н AT(Si). Для простоты администрирования авторизованные задачи должны быть назначены пользовательским ролям, вместо индивидуальных пользователей.

Пользовательская Роль: Субъекты могут быть разделены на категории в зависимости от ролей, которые они могут принимать. Роль: S -> user-role, где user-role = {user, sec-officer, data-protection-officer, tp-manager,...}. Кроме того, должны быть определены дополнительные роли пользователя, если авторизованная задача предназначена для пользовательской роли, а не для индивидуального пользователя.

Пользователям, которые назначены "ответственными" за задачи, должен быть разрешен запрос на назначение этих задач. Следовательно, функция "ответственный" означает: Responsible: T -> 2 S, где Responsible(Ti) является набором субъектов, которые могут запрашивать делегирование Ti.

Цели P: Каждая задача служит для какой-то цели. Кроме того, в некоторых целях собираются личные данные. Цели должны быть выполнимыми для системных приложений.

Функции целей для задач T-Purpose: Каждая задача обслуживает одну единственную цель (однако каждая цель может быть достигнута выполнением различных задач). Функция T-Purpose выражена следующим образом: T -> P, где T-Purpose(Ti) является целью для задачи Ti.

Функция цели для класса объекта O-Purposes: Каждый объектный класс имеет определенные цели, для которых собираются личные данные.

Функция O-Purposes выражена следующим образом: O-class -> 2 P \ ф, где O-Purposes(O-classi) являются целями, для которых был получен объектный класс O-classi. Как показывает практика, не личные данные должны быть пригодны для использования для всех возможных целей: O-Purposes(none) = P.

Процедуры преобразования TRANS: Субъект не имеет произвольного доступа к объекту. Если он выполняет задачу, то он может осуществить некоторые процедуры преобразования, которые позволят получить доступ к объекту в установленном порядке.

Текущая Процедура Преобразования CTP: Процедура преобразования, осуществляемая субъектом в настоящий момент, называется текущей процедурой преобразования. Если субъект в настоящий момент не выполняет никаких процедур преобразования, то значением его процедуры преобразования является Nil. CTP: S -> TRANS х {Nil}.

Авторизованные Процедуры Преобразования ATP: При выполнении задачи субъект авторизован на выполнение некоторых процедур преобразования. ATP: T -> 2 Transх {Nil} \ ф, " Ti н T: Nil н ATP(Ti).

Права доступа A: Права доступа, которые может иметь субъект, определяются атрибутами доступа A = {read, write, append, delete, create}.

Необходимые допуски NA: Для любой задачи, которая обращается к объектным классам для выполнения которых необходима процедура преобразования, они должны быть определены заранее. Это выполняется указанием набора NA м T ╢ O-Class ╢ TRANS ╢ A, который состоит из кортежа вида (Ti, o-classj, transpk, x), где transpk = Nil. (Ti, o-classj, transpk, x) н NA означает, что при выполнении процедуры преобразования transpk, для выполнения задачи Ti, необходимо иметь x-access к объектам объектного класса o-classj.

Текущий набор допусков CA: Текущий x-access для субъекта Si к объекту Oj в даном состоянии представлена кортежем из трех элементов (Si, Oj, x), где x н {read, write, append}. Текущий набор допусков CA м S ╢ O ╢ A является набором кортежей представляющих все текущие допуски.

Уведомление C: В соответствии с большинством национальных законов о защите приватности, обработка и использование личных данных также приемлемы при уведомлении субъекта данных. Набор C м P ╢ O определен как набор кортежей (pi, Oj). Набор кортежей (pi, Oj) означает, что субъект данных уведомлён, что его личные данные, содержащиеся в объекте Oj, использованы при обработке цели pi.


next up previous
Next: Инварианты Up: Формальная Модель Секретности Previous: Формальная Модель Секретности
next up previous
Next: Ограничения Up: Формальная Модель Секретности Previous: Переменные состояния

Инварианты

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

  1. Текущая задача субъекта должна быть авторизована для субъекта (свойство авторизации задачи): " Si: S : CT(Si) I AT(Si).
  2. Текущая процедура трансформации субъекта для текущей задачи субъекта должна быть авторизована (свойство авторизации TP): " Si: S : CTP(Si) I ATP( CT(Si)).
  3. Субъект может иметь доступ только к объектам личных данных, если для выполнения текущей задачи необходим допуск на выполнение процедуры трансформации к объекту данного класса (необходимость обработки данных): " Si:S, Oj:OP: (Si,Oj, x) I CA (CT(Si), Class(Oj ), CTP(Si) , x) I NA.
  4. Субъект может иметь доступ только к объектам личных данных, если цель его текущей задачи соответствует целям, для которых получен объект данного класса, или если это одобрено объектом данных (взаимосвязанность целей): " Si:S, Oj:OP: (Si,Oj, x) I CA
T-Purpose (CT (Si)) I O-Purposes (Class(Oj))U' (T-Purpose( CT(Si)),Oj ) I C

Если пользовательским ролям назначены авторизованные задачи, то в первом инварианте секретности AT(Si) будет заменено на AT(role(Si)).

Пример: Следующий пример демонстрирует различия между концепциями необходимости обработки данных и концепцией взаимосвязанности целей: В больнице, в "лечебных" целях, собраны "данные диагностики". Для исследователя необходимо провести статистический анализ при помощи программы статистики с доступом на чтение к данным диагностики. Таким образом, должны быть назначены соответствующие необходимые права доступа I NA. Задача "статистический анализ" обслуживает цель "исследование". Следовательно, принцип взаимосвязанности целей позволяет получить доступ к даным диагностики пациента в исследовательских целях только с согласия пациента.


next up previous
Next: Ограничения Up: Формальная Модель Секретности Previous: Переменные состояния
next up previous
Next: Управление информационным потоком Up: Формальная Модель Секретности Previous: Инварианты

Ограничения

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

  1. Субъект может создать объект личных данных только в том случае, если это необходимо для его текущей задачи: (CT(subj), o-classk, CTP(subj), create) I" NA U` Oj I" OP Oj I" OP* U' class*(Oj) (1) o-classk
  2. Субъект может удалить объект личных данных только в том случае, если это необходимо для его текущей задачи: (CT(subj), Class(Oj), CTP(subj), delete) I" NA U` Oj I OP Oj I OP*
  3. Субъект может создать объект личных данных только в том случае, если цель его текущей задачи соответствует цели класса объекта o-classk (взаимосвязанность целей): T-Purpose (CT (Si)) I" O-Purposes (o-classk) U` Oj I" OP Oj I" OP* U' class*(Oj) (1) o-classk
  4. Субъект может удалить объект личных данных только в том случае, если цель его текущей задачи соответствует цели класса объекта, или имеется согласие от субъекта данных (взаимосвязанность целей): T-Purpose (CT (Si)) I" O-Purposes (Class(Oj)) U` (T-Purpose( CT(Si)),Oj ) I" C U` Oj I OP Oj I OP*


next up previous
Next: Управление информационным потоком Up: Формальная Модель Секретности Previous: Инварианты
next up previous
Next: Функции перехода состояний Up: Формальная Модель Секретности Previous: Ограничения

Управление информационным потоком

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


Figure 1 - Illegal Information Flow 


Субъект выполняя задачу T1 может читать информацию содержащуюся в объекте O1 и записывать важные данные из O1 в O2. Вследствие этого, другой субъект, выполняющий T2 (с T-Purpose AD), имеет возможность прочитать данные из O1 (с O-Purposes(class(O1) = {MT}), записанные в О2. Это является нарушением принципа взаимосвязанности целей!

В частности, должна быть предотвращена возможность прочтения субъектом объекта личных данных О1 (с O-Purposes(Class(O1)) I` P) и их запись в объект не личных данных О2 (с O-Purposes(Class(O2)) = P).

Можно избежать возникновения незаконного информационного потока, если обеспечиваются следующие условия:

В любом состоянии, если субъект Si имеет одновременный доступ на чтение к объекту О1 и доступ на запись или дополнение к объекту О2, то O-Purposes = (class (O1)) E O-Purposes (class (O2)).

Для соответствия этим условиям в управлении доступом или в сертификации процедуры трансформации программ возможно использование механизма контроля информационного потока.

Простейший механизм контроля потока может быть интегрирован в систему управления доступом операционной системы. Функция Input-Purposes выражена следующим образом: S -> 2P, где Input-Purposes(Si) является набором целей для тех данных, которые могут быть прочитаны Si. Изначально, после создания процесса, Input-Purpose (Si) равен P. Если Si получает доступ на чтение к объекту Oj, то Input-Purposes(Si)*, в новом системном состоянии, принимает значение Input-Purpose (Si) г O-Purposes (class (Oj)).

Если допустить, что Si может не производить запись в объект, полученный с целью не входящей в Input-Purposes (Si), то тем самым возможно предотвратить возникновение незаконного информационного потока. Следующая информация инварианта потока должна помочь избежать незаконного информационного потока:

Инвариант управления незаконным информационным потоком:

" Si: S, Oj:O, x н {write, append} : (Si, Oj, x) н CA => O-Purposes (class (Oj)) м Input-Purposes (Si).

"Секрето-ориентированное состояние" является системным состоянием, соответствующим четырём инвариантам секретности, с 1 по 4, точно так же, как инвариант информационного потока. Последовательность состояний называется "секрето-ориентированной последовательностью состояний", если каждое состояние в последовательности состояний является секрето-ориентированным и все последующие состояния последовательности соответствуют четырем ограничениям секретности 1-4.


next up previous
Next: Функции перехода состояний Up: Формальная Модель Секретности Previous: Ограничения
next up previous
Next: Спецификация и Реализация в Up: Формальная Модель Секретности Previous: Управление информационным потоком

Функции перехода состояний

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

Кроме того, привилегированные функции необходимы для определения или изменения информации управления доступом, такой как задачи, цели, авторизованные задачи для субъектов, авторизованные процедуры преобразования для задач, классы объектов и их цели, необходимые допуски и соглашения. Эти привилегированные функции могут быть выполнены только офицером безопасности. Однако, в случае поддержки "принципа 4-х", администрирование информации управления доступом может быть выполнена совместно с другим человеком, который печётся об интересах секретности субъектов данных. Этот другой человек мог бы быть например, офицером защиты данных в организации или рабочем совете (в соответствии с Немецким постановлением о защите данных, каждая организация, занятая обработкой информации о личности, обязана назначить офицера защиты данных. В директиве ЕС о защите данных присутствует аналогичная роль "соответственного за защиту данных"). Сначала, офицер защиты данных, ответственный за внедрение инструкций секретности в организации и за становление политики секретности, определяет всю необходимую информацию управления доступом. Затем, офицер безопасности отвечающий за внедрение политики безопасности, приводит информацию управления доступом в соответствие этим требованиям.

Для определения и реализации таких схем совместного действия, существует другая системная переменная для "одноразовых" маркеров: Ticket TKT(Si, function-type, parameter-list): составлен для Субъекта Si и отправлен офицеру безопасности (пользователю с ролью "sec-officer"). Это означает, что Si запрашивает у офицера безопасности разрешение на выполнение некоторых функций с некоторыми параметрами. Обычно, составителем маркера является пользователь в роли "data-protection-officer" или пользователь, ответственный за задачу, если авторизация для этой задачи может быть предоставлена или аннулирована от другого субъекта. TKT представляет из себя набор всех составленных маркеров. Офицер охраны с соответствующим маркером может выполнять соответствующую привилегированную функцию:


Figure 2 - Tickets


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


next up previous
Next: Спецификация и Реализация в Up: Формальная Модель Секретности Previous: Управление информационным потоком
next up previous
Next: Архитектура GFAC Up: От Формальной Модели Приватности Previous: Функции перехода состояний

Спецификация и Реализация в соответствии с архитектурой Generalized Framework for Access Control

В проекте определено как должна внедряться политика секретности с соответствии с архитектурой Generalized Framework for Access Control (GFAC) в Unix System V (см. [Fischer-Hu"bner 97b]). GFAC (см. [Abrams et al. 1990], [LaPadula 1995]) это структура для выражения и интеграции многочисленных компонентов безопасности. GFAC позволяет использовать несколько политик безопасности одновременно выбирая для конфигурирования набор свойств (из доступных) необходимый для решения поставленной задачи.

Проектная спецификация верхнего уровня, описывающая как GFAC предписывает политики Bell LaPadula и Clark Wilson, и каким образом могут быть реализованы две поддерживаемых политики (Functional Control (FC) и Security Information Modification (SIM)) в Unix System V, была опубликована в [LaPadula 1995]. В дальнейшем эта спецификация была доработана и дополнена правилами политики модели приватности. Затем она была адаптирована и использована для реализации и интеграции в операционной системе Linux (см. [Ott 1997]) политики секретности по методике GFAC, совместно с другими политиками секретности (Bell LaPadula, FC, SIM). Linux, несмотря на то, что он не был разработан для защиты, был выбран как демонстрационная система потому, что это устойчивая система, доступен её исходный код и она обладает функциональностью System V (рекомендуемая LaPadula система). Вдобавок, он поддерживает большинство основных стандартов Unix. В результате, проект (в частности, модули безопастности Access Decision Facility и Access Control Information) может быть легко перенесён на более защищенную версию Unix.

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

Дополнительно, Linux был дополнен механизмом псевдонимного аудита. Псевдонимный аудит (см. [Sobirey et al. 1997]) это расширяющая секретность технология проверки безопасности, где данные, идентифицирующие пользователя в записях проверки скрыты под псевдонимами.


next up previous
Next: Архитектура GFAC Up: От Формальной Модели Приватности Previous: Функции перехода состояний
next up previous
Next: Средство Управления Доступом (AEF) Up: Спецификация и Реализация в Previous: Спецификация и Реализация в

Архитектура GFAC

В соответствии с с архитектурой GFAC, Защищенная (доверенная) Вычислительная Среда (TCB) состоит из модуля управления доступом (AEF) и модуля принятия решения управления доступом (ADF). ADF реализует принудительную системную политику безопасности и мета-политику для решения, удовлетворяют ли запросы процессов этой политике защиты. AEF использует решения ADF для проведения операций с уместными, в плане безопасности, функциями системного вызова.

В GFAC, система управления доступом ядра системы, разделена на AEF- и ADF-компоненты и модуль ACI для управления Access Control Information (ACI, например, атрибуты безопасности). Схема 3 показывает взаимодействие между компонентами системы. Для каждого уместного, с точки зрения безопасности, системного вызова, например, при обращении процесса к объекту (файлу, каталогу, данным управления защитой (scd) или данным межпроцессного взаимодействия (ipc)), или если процесс желает клонировать себя или послать сигнал, AEF направляет запрос решения к ADF. Параметрами для запроса решения являются тип запроса, описывающий желаемый тип функциональности, идентификация вызывающего процесса и, по возможности, идентификатор цели доступа (субъект или объект). ADF оценивает политику защиты при помощи правил политики для типа запроса и для этих правил необходим ACI. Если затем оценивается его мета-политика, то используются решения различных политик защиты для окончательного определения запроса процесса. Затем AEF реализует решение либо выполнением функций системного вызова, либо возвратив вызывающему процессу сообщение об ошибке. В первом случае, после успешного выполнения, ADF получает уведомление, в следствие чего атрибуты могут быть приведены в соответствие. И наконец, контроль возвращается к процессу.


Figure 3 - GFAC Implementation



next up previous
Next: Средство Управления Доступом (AEF) Up: Спецификация и Реализация в Previous: Спецификация и Реализация в
next up previous
Next: Введение

От Формальной Модели Приватности к Её Реализации

Резюме

Технологии приватности в последнее время становятся всё более и более актуальны, так как индивидуальная секретность в Глобальном Информационном Сообществе подвержена опасности. В этом документе описывается обновлённая версия формальной модели приватности, которая может быть использована для технического внедрения законодательных требований секретности. Этот документ демонстрирует, как может быть определена и реализована политика приватности в соответствии с Generalized Framework for Access Control (GFAC).




next up previous
Next: Введение
next up previous
Next: Реализация On-Access Сканера Интегрированного Up: Методы Интегрированного Обнаружения и Previous: Методы Интегрированного Обнаружения и

Введение

В нашем сетевом сообществе, злонамеренный код (malware) - серьезная угроза защите, секретности и целостности системы. Главные угрозы - это вирусы, которые могут импортировать из Интернет в локальные рабочие станции злонамеренный код и Троянских коней, способных использоватьособенности или слабые места служб Интернет. Макровирусы (вирусы, написанные в интерпретируемом коде используемом приложениями) - это значительный риск, потому что они являются платформо-независимыми, создаются проще, чем 'традиционные' файловые вирусы и содержатся в том, что каждый обычно рассматривает как документы, которыми обмениваются гораздо более часто, чем исполняемыми файлами. Особую угрозу для пользователя представляют технологии которые используют загружаемый код, например ActiveX или Java. Загруженные злонамеренные программы могут воспользоваться брешами в защиты для доступа к жесткому диску пользователя или сети, в поисках важной информации, и заниматься "контрабандой" данных во внешний мир используя сетевое подключение компьютера.

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

В реализации официальной политики безопасности, [Fischer-Hubner 1997], [Fischer- Hubner/Ott 1998], в соответствии с Generalized Framework for Access Control (GFAC, смотри [Abrams et al. 1990]) были представлены методы для систем Linux. Следуя этой документации мы получим интегрированный, реализованный в ядре on-access сканер, путём расширения нашей GFAC-системы за счёт правил сканирования файлов на запросы открытия/выполнения. Интеграция нашего on-access сканера в ядро создаст большую надёжность чем традиционные, не встроенные on-access сканеры.

В этом документе мы покажем как в Generalized Framework for Access Control мы реализовали политику on-access защиты от вирусов при доступе, подобно методике входящей в IBM AntiVirus, включая то, что это реализовано в ядре и, следовательно, лучше защищено от манипуляций. Модель в состоянии сканировать и отказывать в доступе к данным сетевым соединениям происходящим из определенных сетей, путём контроля UNIX-подобных сокетов. В экспериментальной установке Linux мы реализовали оба из этих методов. Мы включили в дальнейшую дискуссию о реализации контроля доступа в области программ различные проблемы, проявившиеся при использовании этих технологий на макровирусах.

В этом документе мы представляем концепцию on-access сканера, реализованного в ядре, с использованием методики GFAC. Между тем, on-access сканеры не могут защитить от злонамеренно реализованного кода, такого как клиентские приложения Java, когда они загружены в память интерпретатора, так как нет субъекта для контроля доступа. Следовательно, далее в этом документе рассматриваются два различных подхода к обнаружению злонамеренного кода: один способ заключается в сканировании передачи данных, позволяя GFAC-системе контролировать доступ на чтение к коммуникационным сокетам. Другой способ кроется в организации мониторинга над окружением программ, защищенным GFAC-системой против манипуляций и контролем/сканированием выполняемого кода.


next up previous
Next: Реализация On-Access Сканера Интегрированного Up: Методы Интегрированного Обнаружения и Previous: Методы Интегрированного Обнаружения и
next up previous
Next: Приложения, необходимые для использования Up: Трудности с выполняемым кодом Previous: Трудности с выполняемым кодом

Размещение контроля доступа нас прикладном уровне

Единственное возможное, и часто осуществляемое решение, это размещение дополнительных мониторов управления доступом на прикладном уровне. Это сделано в языке сценариев веб-броузеров Javaи в VBA, имеющемся в Word for Windows. Преимущество заключается в том, что о синтаксическом анализе позаботится приложение, которое также уверено в собственной объектной модели. Это наиболее оптимальный способ применения мониторов управления доступом.

Сразу становится очевидна одна проблема: механизм безопасности уязвим для атак со стороны прикладного уровня. Поэтому мониторы должны быть ограждены защитой ядра от модифицирующих атак. Security Information Modification (SIM) Policy, разработанная для нашей GFAC-системы, может быть использована для защиты мониторов от неавторизованного изменения. Политика SIM [LaPadula 1995] использует ACI-атрибут data-type с двумя вероятными значениями, "si" и "NIL", точно также, как и system role для пользователя. Если типом запроса доступа процесса к данным является si, в режиме использующем изменение данных, то согласно SIM-политике доступ будет предоставлен только в том случае, если владельцем процесса является "security officer". Следовательно, мониторы в программном окружении должны иметь для атрибута data-type значение si, так они обретут защиту со стороны ядра от манипуляций.

Мы хотели бы немного отойти от темы и упомянуть использование 'сертификатов' в защите приложений. Обычно предлагается составлять сертификаты как аутентификацию для аплетов, таких как Java-аплет, объектов ActiveX или макросов VBA, для уверенности в безопасности этих аплетов. Однако, сами-по-себе сертификаты ничего не решают. Они повышают доверительный уровень аплета, идентифицируя сверх разумных пределов его происхождение. то не защищает аплет от внесения в него злонамеренного кода составителем сертификата.


next up previous
Next: Приложения, необходимые для использования Up: Трудности с выполняемым кодом Previous: Трудности с выполняемым кодом
next up previous
Next: Дальнейшие расширения GFAC Up: Трудности с выполняемым кодом Previous: Размещение контроля доступа нас

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

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

Word 7.0 для Windows мог бы быть перепроектирован для соответствия с такой моделью. Сам Word многие из своих объектов не использует, а для выполнения кода содержащегося в документах пользуется набором объектов принадлежащих VBA (доступ к которому получает при помощи другого набора объектов принадлежащих OLE 2.0). К нашему сожалению, после предоставления программе и документу доступа, контроль доступа к любому другому объекту не может быть использован. Однако, в операционной системе где используется контроль доступа для всех программ, во избежание нарушения безопасности и приватности, может быть реализован принудительный контроль доступа.

Тоже-самое может быть сказано в отношении Java. Java осуществляет гораздо более строгие меры защиты, чем VBA, так как она была создана для использования через Интернет, где не известны намерения поставщика услуг. Однако, назначение политики безопасности остаётся за программой, выполняющей Java, обычно это Веб-броузер. Тип политики безопасности, реализуемый броузером, может быть не совместим с политикой безопасности компании, например, он может не поддерживать разрешенный доступ аплетов Java к локальной файловой системе во встроенных приложениях, но позволять Java-аплету загрузку программного обеспечения на локальный диск в несоблюдение политики компании. Централизованный контроль доступа предоставляет более эффективную защиту.


next up previous
Next: Дальнейшие расширения GFAC Up: Трудности с выполняемым кодом Previous: Размещение контроля доступа нас
next up previous
Next: Заключение Up: Трудности с выполняемым кодом Previous: Приложения, необходимые для использования

Дальнейшие расширения GFAC

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

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

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

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

Аналогичная проблема существует со многими документами HTML. Документ содержит много ссылок к другим документам, таким как изображения и выполняемый код. Обычно, такой код выполняется в пределах виртуальной машины, например, Java, или настоящей, например ActiveX.

Активному содержимому HTML-страниц уделено больше внимания, чем было уделено активному содержимому в обычных документах. Sun проделала большую работу для защиты пользователя от злонамеренных Java аплетов, согласившись в конечном счете, что эту проблему решить невозможно. Microsoft по крайней мере обозначил проблему, хотя и не достаточно, предоставив метод аутентификации объектов ActiveX при помощи сертификатов. Эта схема сертификации распространяется на файлы Word и Excel из состава MS-Office (версии "2000"). Первоначально предполагалось, что большого обмена такими файлами не будет, и выполняемый код оставался бы заключенным на пользовательской машине. Однако, все больше и больше документов Word пересылается по электронной почте и публикуется Интернете, представляя из себя большую угрозу пользовательской безопасности и приватности.

Дальнейшие проблемы возникают, когда мы пробуем придать защите строгую политику. Определенные объекты часто различны по своей природе и в такой ситуации не существует простого способа коррелировать объектный доступ. Например, в VBA программа имеет доступ к встроенному редактору/компилятору и, следовательно, к исходным текстам программы. Хотя любая обычная программа в целом и имеет доступ к файлу, это не предоставляет простого доступа к коду, поскольку это требует сложного синтаксического анализатора формата файла, требующего неопубликованную документацию. Это требовало бы управления доступом к программному коду во избежание активизации VBA-вирусов при обычных операциях с документами.

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


next up previous
Next: Заключение Up: Трудности с выполняемым кодом Previous: Приложения, необходимые для использования
next up previous
Next: Справочный материал: Up: Методы Интегрированного Обнаружения и Previous: Дальнейшие расширения GFAC

Заключение

В этом документе мы продемонстрировали как мы реализовали в Generalize Framework for Access Control on-access политику защиты от вирусов. Эта политика похожа на метод IBM AntiVirus защиты пользователей от вирусов, включая то, что это реализовано в ядре системы и, как следствие, лучше защищено от манипуляций.

Мы также расширили модель до включения сканирования и запрета доступа к данным, исходящего от сетевых соединений под управлением сокетов UNIX-типа. Это полезное, ставшее популярным в последнее время расширение на системах сетевой защиты для предохранения от вирусов. Это способ, превосходящий в некоторых случаях системы сетевой защиты в том, что он ограничивает распространение вирусов в пределах корпорации, вместо просто Интернет - Интранет. Это важный комплимент для политики on-access сканирования, которая предохраняет от вирусов не сохранённых на диске, но работают после загрузки непосредственно в памяти.

Мы реализовали оба этих метода поверх GFAC в экспериментальной установке Linux.

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

В дополнение к трем способам интегрированного обнаружения и предотвращения злонамеренного кода, для обнаружения такого кода в режиме реального времени, может быть использована технология Intrusion Detection Expert System. Концепция первой части для экспериментальной системы вирусного обнаружения была представлена в [Brunnstein/Fischer-Hubner/Swimmer 1991]. Эта система использовала правила априори, основанные на общем поведении вирусов, чтобы обнаруживать и предотвращать вирусоподобное поведение.

И, наконец, наша модель в конечном счете полагается на вирусный сканер, чтобы служить своеобразным "оракулом", для сообщения нам о том, что заданный объект содержит известный вирус. Качество и производительность в этой модели доведены до критических величин. Системы, подобные Computer Immune System [Kephart/Sorkin/Swimmer/White 1997][Kephart et al. 1992], разработанные IBM Research и дополненные Symantec выполнены таким образом, чтобы их реакция на новые вирусы была намного быстрее, чем у существующих в настоящий момент систем, полагающихся в анализе на ограниченные человеческие ресурсы. Часть исследований вошла в осуществляющий автоматический анализ самых высоких стандартов и систем также включающих части VIDES.


next up previous
Next: Справочный материал: Up: Методы Интегрированного Обнаружения и Previous: Дальнейшие расширения GFAC
next up previous
Next: Об Этом Документе Up: Заключение Previous: Заключение

Справочный материал:

[Abrams et al. 1990] Marshall Abrams, K.Eggers, L.LaPadula, I.Olson, "A Generalized Framework for Access Control: An Informal Description", Proceedings of the 13th National Computer Security Conference, Washington, October 1990;

[Brunnstein/Fischer-Hu"bner/Swimmer 1991] Klaus Brunnstein, Simone Fischer-Hu"bner, Morton Swimmer, "Concepts of an Expert System for Virus Detection", in: D.Lindsy, W.L.Price (Eds.): Information Security - Proceedings of the IFIP/Sec91-Conference, Brighton/UK, May 1991, North Holland;

[Fischer-Hu"bner 1997] Simone Fischer-Hu"bner, "A Formal Task-based Privacy Model and its Implementation: An updated Report", Proceedings of the Second Nordic Workshop on Secure Computer Systems NORDSEC'97, Helsinki, November 6-7, 1997;

[Fischer-Hu"bner/Ott 1998] Simone Fischer-Hu"bner, Amon Ott, "From a Formal Privacy Model to its Implementation", Proceedings of the 21st National Information System Security Conference, Arlington, October 1998;

[LaPadula 1995] Leonard LaPadula, "Rule-Set Modelling of Trusted Computer System", Essay 9 in: M.Abrams, S.Jajodia, H. Podell, "Information Security - An integrated Collection of Essays", IEEE Computer Society Press, 1995;

[Ott 1998] Amon Ott, "Rule Set Based Access Control in Linux", http://agn-www.informatik.uni-hamburg.de/people/1ott/rsbac/eng.htm;

[Kephart/Sorkin/Swimmer/White 1997] Jeffrey O. Kephart, Gregory B. Sorkin, Morton Swimmer, Steve R. White, "Blueprint for a Computer Immune System", Proceedings of the Virus Bulleting Conference 1997, http://www.av.ibm.com/InsideTheLab/Bookshelf/ScientificPapers/Kephart/VB97/;

[Kephart 1994], Jeffrey O. Kephart, "A Biologically Inspired Immune System for Computers", Artificial Life IV, Proceedings of the Forth International Workshop on the Synthesis and Simulation of Living Systems, Rodney A. Brools and Pattie Maes, eds, Mass. 1994, http://www.av.ibm.com/InsideTheLab/Bookshelf/ScientificPapers/Kephart/ALIFE4/alife4.distrib.html;

[Aggelis/Gritzalis 1998], George Aggelis and Stefanos Gritzalis, "Security Issues Surrounding Programming Languages for Mobile Code: JAVA vs. Safe-Tcl", ACM SIGOPS, Volume 32, Number 2, April, 1998.


next up previous
Next: Об Этом Документе Up: Заключение Previous: Заключение
next up previous
Up: Заключение Previous: Справочный материал:

Об Этом Документе

Составители:

Перевод:


next up previous
Up: Заключение Previous: Справочный материал:
next up previous
Next: Архитектура GFAC Up: Методы Интегрированного Обнаружения и Previous: Введение

Реализация On-Access Сканера Интегрированного в Ядро с использованием Архитектуры GFAC



next up previous
Next: Архитектура GFAC Up: Методы Интегрированного Обнаружения и Previous: Введение
next up previous
Next: Интеграция Компонентов Правил Политики Up: Реализация On-Access Сканера Интегрированного Previous: Реализация On-Access Сканера Интегрированного

Архитектура GFAC

В проекте Гамбургского Университета, официальной является политика безопасности Bell LaPadula, и две поддерживаемых политики (Security Information Modification-, Functional Control- Policies) реализованы в соответствии с концепцией GFAC в операционных системах Linux (смотри [Fischer-Hubner 1997], [Fischer-Hubner et al. 1998], [Ott 1998]). GFAC это структура для выражения и интеграции многочисленных компонентов безопасности. GFAC позволяет использовать несколько политик безопасности одновременно выбирая для конфигурирования набор свойств (из доступных) необходимый для решения поставленной задачи (смотри [Abrams et al. 1990], [LaPadula 1995]).

В соответствии с с архитектурой GFAC, Защищенная (доверенная) Вычислительная Среда (TCB) состоит из модуля управления доступом (AEF) и модуля принятия решения управления доступом (ADF). ADF реализует принудительную системную политику безопасности и мета-политику для решения, удовлетворяют ли запросы процессов этой политике защиты. AEF использует решения ADF для проведения операций с уместными, в плане безопасности, функциями системного вызова.



В нашей Linux-реализации GFAC (которую мы назвали RSBAC: "Rule-Set Based Access Control"), система контроля доступа ядра разделена на ADF- и AEF-компоненты и модуль ACI, который управляет Access Control Information (ACI, например, атрибуты безопасности) являющимся центральным хранилищем атрибутов безопасности в системе. Схема 1 демонстрирует взаимодействие между компонентами системы. Для каждого уместного, с точки зрения безопасности, системного вызова (если субъект желает получить доступ к объекту) AEF направляет запрос решения к ADF. Параметрами для запроса решения являются тип запроса, описывающий желаемый тип функциональности, идентификацию вызывающего процесса и, по возможности, идентификатор цели доступа (субъект или объект). ADF оценивает политику защиты при помощи правил политики для типа запроса и для этих правил необходим ACI. Если затем оценивается его мета-политика, то используются решения различных политик защиты для окончательного определения запроса процесса. Затем AEF реализует решение либо выполнением функций системного вызова, либо возвратив вызывающему процессу сообщение об ошибке. В первом случае, после успешного выполнения, ADF получает уведомление, в следствие чего атрибуты могут быть приведены в соответствие. И наконец, контроль возвращается к процессу.


next up previous
Next: Интеграция Компонентов Правил Политики Up: Реализация On-Access Сканера Интегрированного Previous: Реализация On-Access Сканера Интегрированного
next up previous
Next: Правила Политики On-Access-сканера: Up: Реализация On-Access Сканера Интегрированного Previous: Архитектура GFAC

Интеграция Компонентов Правил Политики On-Access-сканера

При помощи GFAC-концепции, интегрировав компоненты правил политики сканера в ADF и добавив информацию контроля доступа в модуль администрирования ACI, мы реализовали On-Access-сканер. Хотя GFAC и был первоначально разработан как средство для выражения и интеграции компонент политики формальных моделей защиты (обычно, статическиемодели машинного типа), мы продемонстрируем, что это также может быть использовано для интеграции эвристической политики. В вирусных сканерах всегда присутствует элемент эвристики, так как не существует методов для уверенного определения наличия вируса в файле. Антивирусными средствами в настоящий момент гарантированно могут быть обнаружены только уже известные вирусы. Дополнительные ACI-правила и политики, необходимые для интеграции и реализации компонентов политики сканера, описаны в следующих параграфах.

Информация Контроля Доступа :

Для каждого файла используется новый атрибут защиты MS-scan-result. Допустимыми значениями атрибутов scan-result являются: номер версии, "rejected" (отвергнуто) или "unscanned" (не сканировано). Атрибут файла scan-result имеет значение номера версии сканера, если файл был сканирован с этой версией сканера и не была найдено инфекции. Если файл был сканирован и была обнаружена инфекция, то атрибут файла будет установлен в значение "rejected". Атрибут файла "unscanned" используется в том случае, если файл не был сканирован или претерпел изменения с момента последней проверки.

Также у программ имеется атрибут MS-trusted. Этот атрибут устанавливается для антивирусных и программ резервного копирования, а также для процессов, выполняющих эти программы. Кроме того, ACI-модуль управляет базой данных вирусных образцов/сигнатур, к которым также прикреплён номер версии.


next up previous
Next: Правила Политики On-Access-сканера: Up: Реализация On-Access Сканера Интегрированного Previous: Архитектура GFAC
next up previous
Next: Интеграция Правил On-Access-сканера на Up: Интеграция Компонентов Правил Политики Previous: Интеграция Компонентов Правил Политики

Правила Политики On-Access-сканера:

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

Следовательно, если запросами являются execute, read-open или read-write-open, то правилами принятия решения будут следующие :

Для изменения типов запроса доступа write-open, append-open и truncate нет определённых правил принятия решений. Но не смотря на это, для них и для read-write-open, значение scan-atribute сбрасывается в "unscanned", так как они могут быть и инфицированы и нет.

Интеграция правил сканирования со средством принятия решения о доступе (ADF), не оказывает существенного влияния на работу системы в целом. Для прочтения файла, при запросе на чтение (или чтение-запись), вызываются правила сканирования и, будучи единожды вызваны, остаются резидентно для последующих операций чтения. Кроме того, при открытии на execute-, read-open и read-write-запросах, файлы проверяются только на предмет изменения или соответствия версии сканера, установленного в системе (то есть, если вирусная база данных образца была дополнена и получила новый номер версии). Проблематичными являются комплексные файлы, содержащие и данные и код, которые могут быть проверены чаще, чем это необходимо. К этой проблеме мы вернёмся позднее.


next up previous
Next: Интеграция Правил On-Access-сканера на Up: Интеграция Компонентов Правил Политики Previous: Интеграция Компонентов Правил Политики
next up previous
Next: Краткий обзор Up: Методы Интегрированного Обнаружения и Previous: Правила Политики On-Access-сканера:

Интеграция Правил On-Access-сканера на Уровне Сокетов



next up previous
Next: Краткий обзор Up: Методы Интегрированного Обнаружения и Previous: Правила Политики On-Access-сканера:
next up previous
Next: Реализация Сканера Злонамеренного Кода Up: Интеграция Правил On-Access-сканера на Previous: Интеграция Правил On-Access-сканера на

Краткий обзор

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

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

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

Дополнительные правила сканирования, также являющиеся частью ADF-компонента GFAC-системы, управляют всеми доступами на чтение на сетевых подключениях. Если в потоке данных обнаруживается некий известный злонамеренный код, то дальнейший доступ для чтения отклоняется и возвращается новый код ошибки "malware-detected". Соединение, в зависимости от конфигурации, может быть либо блокировано ядром, либо доверенный процесс может запросить о непрерывной передаче, которая будет ему предоставлена.

Индивидуальная защита каждого компьютера может способствовать уменьшению воздействия злонамеренного кода, проникшего в локальную сеть, миновав систему сетевой защиты. Это может быть вторым уровнем проверки, после системы сетевой защиты. Однако, здесь все-еще присутствует основная проблема с кодированием на программном уровне, свойственная всем системам сетевой защиты, так как пока обнаружению поддаётся только злонамеренный код, набранный открытым текстом.


next up previous
Next: Реализация Сканера Злонамеренного Кода Up: Интеграция Правил On-Access-сканера на Previous: Интеграция Правил On-Access-сканера на
next up previous
Next: Трудности с выполняемым кодом Up: Интеграция Правил On-Access-сканера на Previous: Краткий обзор

Реализация Сканера Злонамеренного Кода на Уровне Сокетов в Ядре Linux

Все сетевые соединения в системе Linux основаны на сокетах. Их-то мы и рассмотрим в этом разделе. Сокеты в целом являются реализациями протоколов, таких как IP, TCP, UDP и ICMP, 3-го и 4-го уровней по ISO-OSI. Для проверки потоков данных UDP и TCP должны контролироваться. Другие протоколы, например SPX/IPX, при желании также могут быть задействованы.

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

Чтение данных осуществляется блоками различных размеров при помощи обычного чтения системных вызовов чтения. Основная функция чтения сокета вызывает функцию чтения назначенную протоколу 4-го уровня. Возвратным значением функции является число байт, прочитанных в этом цикле, или отрицательный код ошибки. Эти значения возвращаются вызывающему процессу.

Наш механизм сканирования, реализованный в настоящее время, вызывается отправкой запроса к ADF для получения типа доступа READ, для цели IPC (Inter-Process Communication), в функциях чтения TCP и UDP, задающих идентификатор сокета, длину и позицию памяти текущего потокового сегмента, а также тип протокола в параметре атрибута.

Если был обнаружен злонамеренный код и, соотвественно, было принято решение "not_granted", то оригинальное возвращаемое значение, длина сегмента, сменяется на код ошибки "malware-detected".

После проверки сегмента данных состояние сканера сохраняется в атрибуте защиты объектов IPC-типа модуля ACI, включая необходимое количество уже прочитанных данных для отступа в алгоритме сканирования, флаг scan-result и размер последнего полученного сегмента.

Как описывалось ранее, при обнаружении злонамеренного кода, в коде принятия решения о допуске, могут иметь место различные действия, в зависимости от типа запрашиваемого процесса. Тогда как TCP-соединение блокируется ядром и закрывается вызывающим процессом, то предпринятие действий в отношении UDP-потока более проблематично, из-за неопределённости идентификатора отправителя.

Для TCP используется ACI-атрибут ms-sock-trusted-tcp, который может иметь три значения:

"not_trusted":
блокированные данные получить невозможно, буфер потокового сегмента очищен
"active":
возвращен код ошибки, но процесс может получить оригинальное возвращаемое значение при помощи дополнительного вызова
"full":
процесс имеет обычный не ограниченный доступ к данным
Каждым процессом выполняющим программу наследуется тот-же атрибут защиты, что используется программой. Текущее решение для UDP реализует тот-же самый механизм, но только при помощи атрибута ms-sock-trusted-udp.

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

Воздействие сканирования на уровне сокетов на сетевую производительность всё-ещё не измерено, но оно определяется, главным образом, алгоритмом сканирования и и количеством выполненных циклов. Основной запрос решения на стандартном Pentium PC, работающем с 10 Mbit Ethernet, как показывают наши тесты для других компонентов RSBAC, не заметен.

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


next up previous
Next: Трудности с выполняемым кодом Up: Интеграция Правил On-Access-сканера на Previous: Краткий обзор
next up previous
Next: Размещение контроля доступа нас Up: Методы Интегрированного Обнаружения и Previous: Реализация Сканера Злонамеренного Кода

Трудности с выполняемым кодом на программном уровне

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



Вот вам пример. Microsoft Word для документов Windows, версии 7 и старше, использует разновидность BASIC, называемую Visual Basic for Applications (VBA). Все объекты, хранимые в этом типе файлов, имеют каталогоподобную структуру, включая текст и выполняемый код (см. рисунок 2). В нашем примере непосредственно сам текст сохранен в объекте с именем "WordDocument", а вирус содержится в "каталоге" \Macros\VBA\, в объекте "groove". Остальные объекты содержат данные, необходимые для использования в служебных целях в Windows и Word.

Если пользователь пишет часть текста в файле, то он пишет только в объекте WordDocument и в этом случае нет смысла проверять файл при открытии в следующий раз, так как код, содержащийся в каталоге \Macros\VBA\, не претерпевает изменений. Однако, если файл управляется системой GFAC, обрабатывающей файлы при контроле как единые объекты, то любой доступ для записи текста в файл приведет к ненужной перепроверке при его открытии в следующий раз.

Если мы попытаемся проверить этот файл на уровне сокетов, то у нес не будет возможности проверить файл в его отдельных объектах. Опыты с IBM AntiVirus показали, что менее надёжно сканирование файла как потока байт, чем парсинг файла и проверка только уместных объектов в каталоге \Macros\VBA.

Аналогичная проблема с шифрованием. Если, например, объект "groovie" зашифрован, то сканер не сможет его проверить. Однако программа в состоянии его дешифровать, тем самым решив эту и другие проблемы защиты, существующие на программном уровне.


next up previous
Next: Размещение контроля доступа нас Up: Методы Интегрированного Обнаружения и Previous: Реализация Сканера Злонамеренного Кода
next up previous
Next: Введение

Методы Интегрированного Обнаружения и Предотвращения Злонамеренного Кода

Резюме:

Описывается реализация политики принудительной вирусной защиты. Эта политика реализуется в рамках Generalized Framework for Access Control (GFAC) на операционных системах Linux. Предлагаемый метод схож с IBM AntiVirus, но обеспечивают большую защиту. Реализациярасширена для включения доступов к сокетам, с целью предотвращения проникновения в систему злонамеренного кода через сетевые подключения. Также рассмотрены вызовы, выполненные в программных кодах (например, так называемые Макровирусы).

Ключевые слова: GFAC, Linux, Malware, Virus, Socket, Spoofing, Security, Privacy, Access Control, Virus Scanner, Java, Visual Basic for Applications (VBA), ActiveX.



next up previous
Next: Введение
next up previous
Next: Введение

Методы Интегрированного Обнаружения и Предотвращения Злонамеренного Кода

Резюме:

Описывается реализация политики принудительной вирусной защиты. Эта политика реализуется в рамках Generalized Framework for Access Control (GFAC) на операционных системах Linux. Предлагаемый метод схож с IBM AntiVirus, но обеспечивают большую защиту. Реализациярасширена для включения доступов к сокетам, с целью предотвращения проникновения в систему злонамеренного кода через сетевые подключения. Также рассмотрены вызовы, выполненные в программных кодах (например, так называемые Макровирусы).

Ключевые слова: GFAC, Linux, Malware, Virus, Socket, Spoofing, Security, Privacy, Access Control, Virus Scanner, Java, Visual Basic for Applications (VBA), ActiveX.



next up previous
Next: Введение
next up previous
Next: Введение Up: Role-Compatibility Модель для Безопасного Previous: Role-Compatibility Модель для Безопасного

Role-Compatibility Model для Безопасного Системного Администрирования

Ключевые слова: Security model, Role-based access control, Generalized Framework for Access Control (GFAC), Web security, Secure Internet server administration



next up previous
Next: Введение Up: Role-Compatibility Модель для Безопасного Previous: Role-Compatibility Модель для Безопасного
next up previous
Next: Сравнение с предыдущими трудами. Up: Role-Compatibility Model для Безопасного Previous: Авторизованные роли:

Пример: Защищенное Администрирование Интернет Сервера

Одна из главных областей серверного применения системы Linux является область Web-серверов. Имеются следующие риски в функционировании системы:

  1. Ошибка в Web-сервере может позволять чтение файлов находящихся вне его публичной области доступа.
  2. Ошибка в Web-сервере может позволять запись файлов находящихся вне его публичной области доступа.
  3. Установленные Вебмастером содержащие ошибки сценарии CGI могут получать доступ к системным файлам нежелательным путём.
  4. Обычными пользователями могут быть установлены без проверки и контроля Вебмастером сценарии CGI дающие доступ к системным файлам нежелательным путём.
Все эти риски могут быть устранены или минимизированы при использовании нашей модели. Для примера мы можем продемонстрироватьпростое решение в котором используются две роли, один объект f/d-типа и один объект IPC-типа:

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

Теперь мы имеем возможность обслуживать нормальные файлы и выполнять сценарии CGI с ролью и правами Webserver. Это полностью решает проблемы 3 и 4, однако всё-еще очень ограничивает в действиях. Так что мы идём далее:

Имейте в виду, что индивидуальная установка rc_force_role также решит проблему 4: Пользователь установивший сценарий CGI выполнит его либо с ролью "Webserver", которая не может сделать ничего плохого, либо должен будет явно установить rc-force-role от "CGI Script" для кого-то обладающего правами MODIFY-ATTRIBUTE для f/d-типа "Web Document". Этот человек также может предотвратить вмешательство с этим сценарием установкой его типа в другое значение.

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

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


next up previous
Next: Сравнение с предыдущими трудами. Up: Role-Compatibility Model для Безопасного Previous: Авторизованные роли:
next up previous
Next: Справочный материал: Up: Role-Compatibility Model для Безопасного Previous: Пример: Защищенное Администрирование Интернет

Сравнение с предыдущими трудами.

Методика RC-модели подобна Domain and Type Enforcement (DTE) [Badger et al. 1995], которая является технологией управления доступом для разделения основной операционной системы, такой как Unix на домены управления доступом. Согласно DTE атрибут контроля доступом называемый доменом (соответствующий роли в RC-модели) ассоциирован с каждым субъектом, а другой атрибут, называемый типом, ассоциирован с каждым объектом. Таблицы представляют разрешенные режимы доступа между доменом и типами и между доменами. В заключительном документе мы сравним RC-модель и DTE более детально. Мы продемонстрируем, что RC-модель не только функциональна как и DTE, но и предоставляет некотрые дополнительные возможности и позволяет настроить более гибкую политику управления доступом.

Кроме того, мы сравним RC-модель и её программы для безопасной организации Web-сервера с моделью RSBAC [Ferraiolo/Kuhn 1992], [Ferraiolo/Cugini/Kuhn 1995] и реализацией RBAC для Web (RBAC/Web) [Ferraiolo/Barkley/Kuhn 1999].


next up previous
Next: Справочный материал: Up: Role-Compatibility Model для Безопасного Previous: Пример: Защищенное Администрирование Интернет
next up previous
Next: Об Этом Документе Up: Role-Compatibility Model для Безопасного Previous: Сравнение с предыдущими трудами.

Справочный материал:

Abrams et al. 1990] Marshall Abrams, K.Eggers, L.LaPadula, I.Olson, "A Generalized Framework for Access Control: An Informal Description", Proceedings of the 13th National Computer Security Conference, Washington, October 1990.

[Badger et al. 1995] Lee Badger, Daniel Sterne, David Sherman, Kenneth Walker, Sheila Haghighat, "Practical Domain and Type Enforcement for UNIX", 1995 IEEE Symposium on Security and Privacy.

[Ferraiolo/Kuhn 1992] D.Ferraiolo, R.Kuhn, "Role-Based Access Controls", Proceedings of the 15th National Computer Security Conference, Baltimore MD, October 1992.

[Ferraiolo/Cugini/Kuhn 1995] D.Ferraiolo, J.Cugini, R.Kuhn, "Role-Based Access Control (RBAC): Features and Motivations", Proceedings of the 11th Computer Security Application Conference, New Orleans, Louisiana, December 11-15, 1995.

[Ferraiolo/Barkley/Kuhn 1997] D.Ferraiolo, J.Barkely, R.Kuhn, "A Role-Based Access Control Model and Reference Implementation Within a Corporate Intranet", ACM Transactions on Information and System Security, Vol.2, No.1, February 1999, pp. 34-64.

[Fischer-Hu"bner/Ott 1998] Simone Fischer-Hu"bner, Amon Ott, "From a Formal Privacy Model to its Implementation", Proceedings of the 21st National Information System Security Conference, Arlington, October 1998.

[LaPadula 1995] Leonard LaPadula, "Rule-Set Modelling of Trusted Computer System", Essay 9 in: M.Abrams, S.Jajodia, H. Podell, "Information Security - An integrated Collection of Essays", IEEE Computer Society Press, 1995.

[Ott/Fischer-Hu"bner/Swimmer 1998] Amon Ott, Simone Fischer-Hu"bner, Morton Swimmer, "Approaches to Integrated Malware Detection and Avoidance", Proceedings of the 3rd Nordic Workshop on Secure IT Systems NORDSEC98, Trondheim, November 5-6, 1998, [*].


next up previous
Next: Об Этом Документе Up: Role-Compatibility Model для Безопасного Previous: Сравнение с предыдущими трудами.
next up previous
Up: Role-Compatibility Model для Безопасного Previous: Справочный материал:

Об Этом Документе

Составители:

Перевод:


next up previous
Up: Role-Compatibility Model для Безопасного Previous: Справочный материал:
next up previous
Next: Role-Compatibility (RC) Model Up: Role-Compatibility Model для Безопасного Previous: Role-Compatibility Model для Безопасного

Введение

Недавно, появилось и получило признание как метод управления защитой, ролевое управление доступом.

Мы создали Role-Compatibility Model (RC Model), которая может быть использована для представления ролей в виде наборовнаборов прав доступа к совместимым типам объектов, что является наиболее полезным для безопасного администрирования системы и особенно для улучшения защиты Unix. В проект RSBAC (Rule-Set Based Access Control), вкупе с политикой защиты Generalized Framework for Access Control (GFAC) для операционных систем Linux, был реализован в рамках проекта Role-Compatibility Policy.

В этом документе мы представляем RC-модель и сопоставляем её со схожими реализациями защиты, такими как RBAC (Role-Based Access Control) and DTE (Domain Type Enforcement). Кроме того мы подчеркнём её реализацию в Linux с использованием GFAC. Наконец, мы приведём примеры того, как RC-модель может использоваться для улучшения защиты в Unix и особенно для безопасного администрирования Internet-сервера.


next up previous
Next: Role-Compatibility (RC) Model Up: Role-Compatibility Model для Безопасного Previous: Role-Compatibility Model для Безопасного
next up previous
Next: Концепция защиты: Up: Role-Compatibility Model для Безопасного Previous: Введение

Role-Compatibility (RC) Model



next up previous
Next: Концепция защиты: Up: Role-Compatibility Model для Безопасного Previous: Введение
next up previous
Next: Объекты и типы объектов: Up: Role-Compatibility (RC) Model Previous: Role-Compatibility (RC) Model

Концепция защиты:

Концепция защиты Role-Compatibility Model может быть охарактеризована следующим образом:

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

Пользователи и процессы:

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

Владельцем каждого процесса является пользователь:

owner(p:process) = {пользователь, который является владельцем процесса "p"}


next up previous
Next: Объекты и типы объектов: Up: Role-Compatibility (RC) Model Previous: Role-Compatibility (RC) Model
next up previous
Next: Роли и модели доступа: Up: Role-Compatibility (RC) Model Previous: Концепция защиты:

Объекты и типы объектов:

В RC-модели защищенными объектами являются любые из класса "f/d" (файлы или каталоги), "ipc" (объекты межпроцессного взаимодействия, такие как разделяемая память, запросы или сокеты), "dev" (файлы устройств), "scd" (данные контроля системы системные данные такие как порты ввода/вывода, часы и т.д. ) и "процессы" (объекты также могут быть субъектами).

Объекты могут быть разбиты на категории в соответствии с их типами:

rc-type(o:object) = тип объекта "o"
Например, типы "general" (для объектов доступных всем типам пользователей), "system" (для объектов доступных только пользователям в роли "system admnistrator") и "security" (для объектов доступных только в роли "security officer") могут быть использованы для приведения политики Functional Control (FC) к предопределенному [LaPadula, 1995]. Тип файл/каталог также может иметь специальное значение "inherit-from-parent", что означает - тип объекта эквивалентен типу его родительского каталога.


next up previous
Next: Роли и модели доступа: Up: Role-Compatibility (RC) Model Previous: Концепция защиты:
next up previous
Next: Правила функционирования Up: Role-Compatibility (RC) Model Previous: Объекты и типы объектов:

Роли и модели доступа:

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

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

access-modes(f/d) = {ADD-TO-KERNEL, APPEND-OPEN, CHANGE-GROUP, CHANGE-OWNER, CHDIR, CLOSE, CREATE, DELETE, EXECUTE, GET-PERMISSIONS-DATA, GET-STATUS-DATA, MODIFY-ACCESS-DATA, MODIFY-ATTRIBUTE, MODIFY-PERMISSIONS-DATA, MOUNT, READ, READ-ATTRIBUTE, READ-OPEN, READ-WRITE-OPEN, RENAME, SEARCH, TRUNCATE, UMOUNT, WRITE, WRITE-OPEN}

access-modes(ipc) = {ALTER, APPEND-OPEN, CHANGE-GROUP, CHANGE-OWNER, CLOSE, CREATE, DELETE, GET-PERMISSIONS-DATA, GET-STATUS-DATA, MODIFY-ATTRIBUTE, MODIFY-PERMISSIONS-DATA, READ, READ-ATTRIBUTE, READ-OPEN, READ-WRITE-OPEN, WRITE-OPEN}

access-modes(dev) = {APPEND-OPEN, CHANGE-GROUP, CHANGE-OWNER, CLOSE, MODIFY-ATTRIBUTE, MOUNT, READ-ATTRIBUTE, READ-OPEN, READ-WRITE-OPEN, UMOUNT, WRITE-OPEN}

access-modes(scd) = {GET-PERMISSIONS-DATA, GET-STATUS-DATA, MODIFY-ATTRIBUTE, MODIFY-PERMISSIONS-DATA, MODIFY-SYSTEM-DATA, READ-ATTRIBUTE, REMOVE-FROM-KERNEL, SHUTDOWN, WRITE}

access-modes(process) = {CHANGE-GROUP, CHANGE-OWNER, CLONE, CREATE, MODIFY-ATTRIBUTE, READ-ATTRIBUTE, SEND-SIGNAL, TERMINATE, TRACE}

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

Кроме того возможно задание типов вновь создаваемых объектов для данной роли. Для предотвращения создания объектов может быть использовано предопределённое значение "no-create". Специальные значения типов, такие как "type-inherit-parent" (или "type-inherit-process") могут быть использованы для наследования типа родительского каталога (или родительского процесса).

Также для каждой роли может сыть определен тип процесса после процедуры смены владельца или запуска нового процесса. Для отклонения этих запросов здесь могут использоваться специальные значения "no_chown" и "no_execute".

Каждый пользователь имеет заданную по умолчанию роль, наследуемую его процессами.

rc-default-role: def-role(u:user) = роль по умолчанию, заданная для пользователя "u", и начальная роль процессов, принадлежащих "u" после их создания, а так же после каждого изменения владельца (инициированного вызовом функции setuid).

Каждый процесс, в отдельно взятый момент времени, выполняет одну роль.

rc-role(p:process) = текущая, выполняемая процессом "p", роль
Дочерний процесс наследует rc-role от своего родительского. Это может быть изменено с использованием механизма force-role (см.ниже). При настройках по умолчанию роль изменяется только в случае изменения владельца процесса.


next up previous
Next: Правила функционирования Up: Role-Compatibility (RC) Model Previous: Объекты и типы объектов:
next up previous
Next: Форсированные роли: Up: Role-Compatibility (RC) Model Previous: Роли и модели доступа:

Правила функционирования

Правило 1: Первый процесс p1 (init) получает заданную по умолчанию роль системного пользователя root:

rc-role (p1) = rc-def-role (root)
Примечание: Здесь и дальше символ * после некоторого обозначения будет означать его новое состояние. Например (rc-role)* - новое значение роли.

Правило 2: После создания процесса, текущей ролью pnew является роль его родительского процесса p:

if request = CLONE(p) and request is granted

then rc-role*(pnew) = rc-role (p)

Правило 3.1: После создания процесса (forced role) или изменения владельца процесса текущей ролью нового процесса p становится роль определенная как роль по умолчанию у нового владельца:

if request = CHANGE-OWNER(p) and request is granted

then rc-role*(p) = rc-default-roledef-role(owner*(p))


next up previous
Next: Форсированные роли: Up: Role-Compatibility (RC) Model Previous: Роли и модели доступа:
next up previous
Next: Авторизованные роли: Up: Правила функционирования Previous: Правила функционирования

Форсированные роли:

Важным принципом защиты для сохранения целостности является запрещение произвольного доступа субъектов к данным объекта, и последующее разрешение доступа к данным только определённым способом, выполнением четко определённых программ. Наша модель допускает принудительное соблюдение этого принципа через концепцию "форсированных ролей". Каждый исполняемый файл имеет атрибут rc_forced_role, который имеет либо значение NIL (не форсированная роль), либо определяет так называемуюфорсированную роль? которую получит процесс при запуске данного файла. Все это очень похоже на стандартный механизм Unix SUID.

Концепция форсированной роли может быть использована для ограничения привилегий суперпользователя в Unix системах, например для ограничения доступа к авторизационной информации (/etc/passwd, /etc/shadow) для некоторых программ с форсированной ролью "Autorisation". Пример:...

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


next up previous
Next: Авторизованные роли: Up: Правила функционирования Previous: Правила функционирования
next up previous
Next: Пример: Защищенное Администрирование Интернет Up: Правила функционирования Previous: Форсированные роли:

Авторизованные роли:

Процесс проходит авторизацию для своей первоначальной роли (которая является заданной по умолчанию ролью его владельца создавшего родительский процесс или ролью root в случае первого процесса (init)) и для всех последующих ролей которые он может иметь.

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

Формально это правило может быть выражено следующим образом:

Правило 3.4: `` p:process,rolem,rolen:role:

rc-role(p) = rolem => rc-role*(p) = rolen

с rolen = rolem или rolen rolem совместима с rolem rolen

или rolen = rc-def-role(владелец*(p))

или rolen = rc-forced-role*(p).

В зависимости от процесса текущий допуск роли к объектам некоторых "подходящих" типов либо разрешён, либо запрещен.

Правило 5: `` p:process, o:object:

p получит доступ к o с правами x, если rc-role(p) совместима с (типом(o), в режиме доступа x)


next up previous
Next: Пример: Защищенное Администрирование Интернет Up: Правила функционирования Previous: Форсированные роли:
next up previous
Next: Role-Compatibility Model для Безопасного

Role-Compatibility Модель для Безопасного Системного Администрирования




next up previous
Next: Role-Compatibility Model для Безопасного
next up previous
Next: Role-Compatibility Model для Безопасного

Role-Compatibility Модель для Безопасного Системного Администрирования




next up previous
Next: Role-Compatibility Model для Безопасного
next up previous
Next: Основы Up: Rule Set Based Access Previous: Rule Set Based Access

Регистрация Модулей (REG)



next up previous
Next: Основы Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Преобразование Значения в Имя Up: Вспомогательные Функции RSBAC Previous: Вспомогательные Функции RSBAC

Общие Списки

С версии 1.1.2 RSBAC предоставляет постоянные общие списки с настраиваемым индексом и размером данных и автоматическим созданием резервных proc-файлов. Полное описание будет в ближайшее время. А пока, пожалуйста, смотрите заголовочный файл include/rsbac/lists.h.


next up previous
Next: Преобразование Значения в Имя Up: Вспомогательные Функции RSBAC Previous: Вспомогательные Функции RSBAC
next up previous
Next: Протоколирование в Системе Up: Вспомогательные Функции RSBAC Previous: Общие Списки

Преобразование Значения в Имя

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

char name[RSBAC_MAXNAMELEN];
достаточно для всех функции, за исключением target_id_name, если в конфигурации ядра задействовано использование полного имени в протоколировании. В этом случае делается один лист (Linux macro PAGE_SIZE).

Эти, и некоторые name-to-value-функции, могут быть также использованы в пользовательском инструментарии, просто скопируйте getname.c, скомпилируйте его в getname.o и соедините с вашей программой. Загляните в инструментарий администратора RSBAC, что бы видеть как это используется.

#include  <rsbac/getname.h>

char * get_request_name

  (char * request_name, 

   enum rsbac_adf_request_t request);

char * get_attribute_name

  (char * attr_name, 

   enum rsbac_attribute_t attr);

char * get_scd_type_name

  (char * res_name, 

   enum rsbac_scd_type_t res);

сhar * get_target_name

  (char * target_type_name, 

   enum rsbac_target_t target, 

   char * target_id_name, 

   union rsbac_target_id_t tid);

/* returns target_type_name. */

/* target_id_name includes full identification

   with id numbers and path */

char * get_switch_target_name

  (char * switch_name, 

   enum rsbac_switch_target_t target);

/* fixed module names */

char * get_error_name

  (char * error_name, 

   int error);

/* RSBAC error names only, other values are

   returned as decimal numbers. */


next up previous
Next: Протоколирование в Системе Up: Вспомогательные Функции RSBAC Previous: Общие Списки
next up previous
Next: Доступ в Пользовательское Пространство Up: Вспомогательные Функции RSBAC Previous: Преобразование Значения в Имя

Протоколирование в Системе

#include <rsbac/debug.h>

   extern int rsbac_printk(const char *, ...); 

    /* log to rsbac log - use like printk(9) */


next up previous
Next: Доступ в Пользовательское Пространство Up: Вспомогательные Функции RSBAC Previous: Преобразование Значения в Имя
next up previous
Next: Главные Атрибуты Up: Вспомогательные Функции RSBAC Previous: Протоколирование в Системе

Доступ в Пользовательское Пространство

#include <rsbac/helpers.h>

   int rsbac_get_user 

      (unsigned char * kern_p, unsigned char * user_p, int len); 

    /* get data from user space */

    int rsbac_put_user 

      (unsigned char * kern_p, unsigned char * user_p, int len); 

    /* put data to user space */

    char * rsbac_getname(const char * name); 

    /* allocate a page and copy name from userspace */

    void rsbac_putname(const char * name); 

    /* deallocate the page */ 


next up previous
Next: Главные Атрибуты Up: Вспомогательные Функции RSBAC Previous: Протоколирование в Системе
next up previous
Next: Доступ к Базе ACI Up: Вспомогательные Функции RSBAC Previous: Доступ в Пользовательское Пространство

Главные Атрибуты

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

#include <rsbac/aci.h>

    int rsbac_get_attr 

      (enum rsbac_target_t target, 

       union rsbac_target_id_t tid, 

       enum rsbac_attribute_t attr, 

       union rsbac_attribute_value_t * attr_val_p, boolean inherit); 

    /* read an attribute value, possibly inherited */

    int rsbac_set_attr 

      (enum rsbac_target_t target, 

       union rsbac_target_id_t tid, 

       enum rsbac_attribute_t attr, 

       union rsbac_attribute_value_t attr_val); 

    /* modify attribute value - automatically creates 

       a list item, if not yet there */

    int rsbac_remove_target 

      (enum rsbac_target_t target, 

       union rsbac_target_id_t tid); 

    /* remove list item -> reset all values to defaults */


next up previous
Next: Доступ к Базе ACI Up: Вспомогательные Функции RSBAC Previous: Доступ в Пользовательское Пространство
next up previous
Next: Регистрация Proc файлов/каталогов Up: Регистрация Модулей (REG) Previous: Главные Атрибуты

Доступ к Базе ACI

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

Предупреждение: чтение и запись из и в область ядра требует изменение дескриптора сегмента - смотрите reg_sample2.c как пример того, как это все делается.

#include <rsbac/aci_data_structures.h>

    kdev_t rsbac_root_dev; /* System root device */

    extern struct semaphore rsbac_write_sem; 

    /* semaphore, to be held when writing to rsbac dir */

    int rsbac_read_open (char *filename, 

                         struct file *file, 

                         kdev_t dev);

    /* read-open a file in protected rsbac dir on 

       device dev. filename must be basename (no /). */

    int rsbac_write_open(char *filename, 

                         struct file *file, 

                         kdev_t kdev);

    /* same for write-open */

       void rsbac_read_close(struct file *); 

    /* close with cleanup */

       void rsbac_write_close(struct file *);


next up previous
Next: Регистрация Proc файлов/каталогов Up: Регистрация Модулей (REG) Previous: Главные Атрибуты
next up previous
Next: Об Этом Документе Up: Доступ к Базе ACI Previous: Доступ к Базе ACI

Регистрация Proc файлов/каталогов

Для регистрации в этих каталогах используйте пожалуйста стандартные функции ядра Linux create_proc_entry() и remove_proc_entry().

#include <rsbac/procfs.h>

   struct proc_dir_entry * proc_rsbac_root_p; 

   /* rsbac proc root for /proc/rsbac-info */

   struct proc_dir_entry * proc_rsbac_backup_p; 

   /* /proc/rsbac-info/backup for ds raw backup */


next up previous
Next: Об Этом Документе Up: Доступ к Базе ACI Previous: Доступ к Базе ACI
next up previous
Up: Регистрация Модулей (REG) Previous: Регистрация Proc файлов/каталогов

Об Этом Документе

Составитель:

Перевод:


next up previous
Up: Регистрация Модулей (REG) Previous: Регистрация Proc файлов/каталогов
next up previous
Next: Регистрация Модуля Up: Регистрация Модулей (REG) Previous: Регистрация Модулей (REG)

Основы

REG - это не модуль принятия решения. Это - интерфейс для регистрации вашего собственного модуля решения, который может быть, но не обязательно, реализован как модуль ядра Linux. Он допускает регистрацию для всех подходящих запросов к коду решения также как для запросов обслуживания к данным структуирующим выполнение. Начиная с версии 1.1.1-pre4 он также допускает регистрацию системных вызовов в syscall-диспетчере REG.

В rsbac/adf/reg/adf_sample*.c вы можете найти пример модулей ядра. Если вы выберете в конфигурации ядра 'Compile REG samples', то примеры будут скомпилированы и установлены как и все прочие модули.

Если Вы предпочитаете отдельную компиляцию модулей, то в пакете rsbac-admin есть примеры таких модулей с действующим Makefile и (с версии 1.1.1-pre4) демонстрационным инструментарием syscall-диспетчера.

Пожалуйста, обратите внимание, что этот текст ориентирован на RSBAC начиная с версии 1.1.1-pre4, из-за добавленных функциональных возможностей и (я надеюсь) более легкого использования.


next up previous
Next: Регистрация Модуля Up: Регистрация Модулей (REG) Previous: Регистрация Модулей (REG)
next up previous
Next: Callback-функции Up: Регистрация Модулей (REG) Previous: Основы

Регистрация Модуля

Вся процедура регистрации модуля решения осуществляется с использованием идентификаторов rsbac_reg_handle_t, которые являются 32-битным числом. Как правило положительные значения используются как реальные значения и отрицательные для ошибок.

Типы данных и определения функций REG могут быть найдены в include/rsbac/reg.h, все остальное находятся в include/rsbac/types.h. Эти файлы заголовков должны быть всегда включены в вашу реализацию модели.

Полный список запросов RSBAC с возможными целями находится в документе, описывающем Цели и Запросы [*].


next up previous
Next: Callback-функции Up: Регистрация Модулей (REG) Previous: Основы
next up previous
Next: Функции Регистрации Up: Регистрация Модуля Previous: Регистрация Модуля

Callback-функции

Вы можете регистрировать следующие функции:

int rsbac_reg_request_func_t 

  ( enum rsbac_adf_request_t request, 

         rsbac_pid_t caller_pid, 

    enum rsbac_target_t target, 

    union rsbac_target_id_t tid, 

    enum rsbac_attribute_t attr, 

    union rsbac_attribute_value_t attr_val, 

    rsbac_uid_t owner); /* process owner */

int rsbac_reg_set_attr_func_t 

  ( enum rsbac_adf_request_t request, 

         rsbac_pid_t caller_pid, 

    enum rsbac_target_t target, 

    union rsbac_target_id_t tid, 

    enum rsbac_target_t new_target, 

    union rsbac_target_id_t new_tid, 

    enum rsbac_attribute_t attr, 

    union rsbac_attribute_value_t attr_val, 

    rsbac_uid_t owner); /* process owner */

boolean rsbac_reg_need_overwrite_func 

  (struct dentry * dentry_p);

Параметр need_lock сообщает, что в окружение функции write-to-disk должны быть помещены функции ядра lock_kernel() / unlock_kernel(). К сожалению этот параметр меняется в зависимости от функции вызывающего rsbac_write. Возвращаемое значение является числом записанных списков (0 или более) или отрицательным значением ошибки, например значением, возвращенным rsbac_write_open.

int rsbac_reg_write_func_t(boolean need_lock);
Если правильное значение не равно 0, то ошибки должны быть автоматически исправлены. Если check_inode не 0, то числа ссылающиеся на иноды тоже будут проверены. В случае нормального завершения возвращаемое значение - 0, иное - ошибка.

int rsbac_reg_check_func_t(int correct, int check_inode);
int rsbac_reg_mount_func_t(kdev_t kdev);
int rsbac_reg_umount_func_t(kdev_t kdev);


next up previous
Next: Функции Регистрации Up: Регистрация Модуля Previous: Регистрация Модуля
next up previous
Next: Регистрация Системных Вызовов Up: Регистрация Модуля Previous: Callback-функции

Функции Регистрации

Для регистрации модуля вы сначала выбираете положительное, 32-х Битное целое со знаком число, это будет ваш персональный дескриптор. Он будет требоваться при всех дальнейших процедурах связанных с регистрацией. Если случится так, что выбранный вами дескриптор в данный момент используется, то вам будет отказано в регистрации со значением ошибки - RSBAC_EEXIST.

rsbac_reg_syscall_entry в struct содержит все необходимые значения. Функция может быть не учтена установкой ее указателя в значение NULL. Ваш модуль позднее будет идентифицирован в сообщениях REG и proc-файлах по его имени. Текущая максимальная длина имени 30 знаков.

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

struct rsbac_reg_entry_t 

   { 

    rsbac_reg_handle_t                  handle; 

    char                                name[RSBAC_REG_NAME_LEN+1];

    rsbac_reg_request_func_t          * request_func; 

    rsbac_reg_set_attr_func_t         * set_attr_func; 

    rsbac_reg_need_overwrite_func_t   * need_overwrite_func; 

    rsbac_reg_write_func_t            * write_func; 

    rsbac_reg_mount_func_t            * mount_func; 

    rsbac_reg_umount_func_t           * umount_func; 

    boolean                             switch_on;  /* turned on initially? */ 

};

Заданная этой struct регистрация весьма легка. Обычно регистрация происходит в функции init_module() модуля ядра, де-регистрация в cleanup_module(). Выгрузка модуля, зарегистрированного REG, без де-регистрации убьет вашу систему!

Единственная вещь, добавленная к вхождению struct это значение версии REG, которое позволит производить проверку версий для модулей поставляемых в бинарном виде. Оно должно быть всегда установлено в значение RSBAC_REG_VERSION. Функция регистрации возвратит ва положительный дескриптор или отрицательный код ошибки (для дополнительной информации смотри include/rsbac/reg.h).

rsbac_reg_handle_t rsbac_reg_register 

  (       rsbac_version_t      version, 

   struct rsbac_reg_entry_t entry);

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

int rsbac_reg_switch 

  (rsbac_reg_handle_t handle, boolean value);

Дерегистрация очень проста.

int rsbac_reg_unregister 

  (rsbac_reg_handle_t handle);

ОК! Теперь ваша модель должна работать. Если она также регистрирует syscall- или proc-вхождения, то вы теперь можете взглянуть на его статус.

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


next up previous
Next: Регистрация Системных Вызовов Up: Регистрация Модуля Previous: Callback-функции
next up previous
Next: Функции Обратного Вызова Up: Регистрация Модулей (REG) Previous: Функции Регистрации

Регистрация Системных Вызовов

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

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

Ваш системный вызов, будучи однажды зарегистрированным, может быть вызван официальным системным вызовом:

int sys_rsbac_reg 

  (rsbac_reg_handle_t handle, 

   void * arg);

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


next up previous
Next: Функции Обратного Вызова Up: Регистрация Модулей (REG) Previous: Функции Регистрации
next up previous
Next: Функции Регистрации. Up: Регистрация Системных Вызовов Previous: Регистрация Системных Вызовов

Функции Обратного Вызова

Ваша -syscall-функция должна выглядеть следующим образом:

int rsbac_reg_syscall_func_t(void * data);
Указатель этой функции теперь получит пользовательский указатель. Для работы с вашими данными вы должны сначала получить его из пользовательской области при помощи:

#include <rsbac/helpers.h>

int rsbac_get_user 

  (unsigned char * kern_p, unsigned char * user_p, int size);

Возвращаемый код вашей функции будет передан вызывающему процессу.


next up previous
Next: Функции Регистрации. Up: Регистрация Системных Вызовов Previous: Регистрация Системных Вызовов
next up previous
Next: Вспомогательные Функции RSBAC Up: Регистрация Системных Вызовов Previous: Функции Обратного Вызова

Функции Регистрации.

Теперь, для регистрации syscall, вы выбираете положительное, 32-х Битное целое со знаком число, как ваш персональный дескриптор и другое, подписанное 32-х Битное со знаком значение, как ваш публичный дескриптор syscall-диспетчера. Все действия, связанные с регистрацией, позднее будут нуждаться в этом уникальном секретном дескрипторе. Если случится так, что ваш дескриптор в данный момент используется, то вам будет отказано в регистрации со значением ошибки - RSBAC_EEXIST.

struct rsbac_reg_syscall_entry хранит в себе все необходимые значения. Может быть не учтено только имя. Ваш системный вызов позже будет идентифицирован в сообщениях REG и proc-файлах по их имени и дескриптору публичного диспетчера. Текущая максимальная длина имени ограничена 30 знаками.

struct rsbac_reg_syscall_entry_t 

  { 

    rsbac_reg_handle_t              registration_handle; 

    rsbac_reg_handle_t              dispatcher_handle; 

    char                            name[RSBAC_REG_NAME_LEN+1]; 

    rsbac_reg_syscall_func_t      * syscall_func; 

  };

Заданная этой struct регистрация похожа на регистрацию модулем принятия решения. Выгрузка модуля с зарегистрированным syscall без де-регистрации убьет вашу системы при следующем обращении к syscall-функции!

Заново добавленное во вхождение struct является значением версии REG, что позволит производить проверку версии для модулей полученных в бинарном виде. Оно всегда должно быть установлено в RSBAC_REG_VERSION. Функция регистрации возвратит ваш положительный дескриптор или отрицательный код ошибки (для дополнительной информации смотри include/rsbac/reg.h)

rsbac_reg_handle_t rsbac_reg_register_syscall 

  (       rsbac_version_t           version, 

   struct rsbac_reg_syscall_entry_t entry);

Однажды зарегистрировав, вы сможете использовать ваши системные вызовы. Де-регистрация теперь проста.

int rsbac_reg_unregister_syscall 

  (rsbac_reg_handle_t registration_handle);

Очередной намек на примеры модулей.


next up previous
Next: Вспомогательные Функции RSBAC Up: Регистрация Системных Вызовов Previous: Функции Обратного Вызова
next up previous
Next: Общие Списки Up: Регистрация Модулей (REG) Previous: Функции Регистрации.

Вспомогательные Функции RSBAC

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



next up previous
Next: Общие Списки Up: Регистрация Модулей (REG) Previous: Функции Регистрации.
next up previous
Next: Регистрация Модулей (REG)

Rule Set Based Access Control (RSBAC) для Linux - Регистрация Модулей




next up previous
Next: Регистрация Модулей (REG)
next up previous
Next: Регистрация Модулей (REG)

Rule Set Based Access Control (RSBAC) для Linux - Регистрация Модулей




next up previous
Next: Регистрация Модулей (REG)
next up previous
Next: Основные Положения Up: Rule Set Based Access Previous: Rule Set Based Access

Распределение Памяти



next up previous
Next: Основные Положения Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Распределение Памяти в RSBAC Up: Распределение Памяти Previous: Распределение Памяти

Основные Положения

Для различных задач необходимо распределить области памяти. Особенно в ядре Linux, где пространство стека довольно сильно заполнено, так что часто Вы просто не сможете объявить большую переменную и надеяться, что она сработает.

Обычный способ распределения памяти заключается в использовании kmalloc/kfree при довольно малых количествах (размещенных неразрывно как реальная память) и vmalloc/vfree (виртуальной памяти) при больших размерах. К сожалению, вы сами должны определить какой способ для вас предпочтительнее. kmalloc вызовет ошибку при попытке размещения более чем 128М - так или иначе, доступ к непрерывной памяти на нескольких страницах может быть затруднителен.


next up previous
Next: Распределение Памяти в RSBAC Up: Распределение Памяти Previous: Распределение Памяти
next up previous
Next: Об этом Документе Up: Распределение Памяти Previous: Основные Положения

Распределение Памяти в RSBAC

Начиная с версии 1.1.2 RSBAC предоставляет собственные функции управления памятью. Также, при включенной поддержке REG, эти функции экспортируются для модулей.

В версиях ядра с 2.4.0 отдельные участки памяти используются как память kmalloc-стиля для предоставления лучшего контроля над использованием памяти через /proc/slabinfo.

#include <rsbac/rkmem.h>
void * rsbac_kmalloc (size_t size);
void rsbac_kfree (const void *objp);
void * rsbac_vkmalloc 

(size_t size, boolean * vmalloc_used_p);

void rsbac_vkfree (void *objp, boolean vmalloc_used);


next up previous
Next: Об этом Документе Up: Распределение Памяти Previous: Основные Положения
next up previous
Up: Распределение Памяти Previous: Распределение Памяти в RSBAC

Об этом Документе

Составитель:

Перевод:


next up previous
Up: Распределение Памяти Previous: Распределение Памяти в RSBAC
next up previous
Next: Распределение Памяти

Rule Set Based Access Control (RSBAC) для Linux - Распределение Памяти




next up previous
Next: Распределение Памяти
next up previous
Next: Распределение Памяти

Rule Set Based Access Control (RSBAC) для Linux - Распределение Памяти




next up previous
Next: Распределение Памяти
next up previous
Next: Запросы Up: Rule Set Based Access Previous: Rule Set Based Access

Цели

RSBAC разграничивает доступ от субъектов к объектам. Субъектом всегда является процесс, действующий со стороны пользователя с определенными атрибутами. Объекты в RSBAC называются Target (Цель). Определяются следующие типы объектов:

FILE Файлы, включая специальные файлы устройств. Идентифицируются по устройствам и номерам inode.
DIR Каталоги, идентифицированные по устройствам и номерам inode.
FIFO (впервые появились в v1.1.1) специальные файлы FIFO.
DEV Устройства, различаемые по типу (char или block), значениям major и minor.
IPC InterProcess Communication: Semaphores (sem), Messages (msg), Shared Memory (shm), Sockets (sock) и FiFo (fifo, удалено в 1.1.1).
SCD System Control Data: Объекты затрагивающие всю систему. Цели этого типа являются единственными с фиксированным числом объекта, идентифицируемому по по номеру (смотри ниже).
USER Пользователи как объекты, в основном для информации контроля доступа (ACI).
PROCESS Процессы как объекты.
NONE Нет объектов, ассоциированных с этим запросом. В некоторых моделях (RC, ACL) это приравнено к SCD-цели "other".
FD (Только в пользовательской области): Позволяет средствам командной строки делать различие между типами FILE и DIR.

Цели System Control Data (SCD) выглядят следующим образом:

time_strucs Системный таймер
clock Системные время и дата
host_id Имя машины
net_id Имя домена
ioports Access Control для прямого доступа к оборудованию
rlimit Установка ограничения ресурсов процесса
swap Контроль свопирования
syslog Системный журнал регистрации событий
rsbac Данные RSBAC в /proc
rsbaclog Собственный журнал регистрации событий RSBAC
kmem Прямой доступ к памяти ядра через proc или устройство
other (только встроенное в RC и ACL): Подстановка для цели NONE
auth_administration (только в RC и ACL): AUTH-модель администрирования


next up previous
Next: Запросы Up: Rule Set Based Access Previous: Rule Set Based Access
next up previous
Next: Об Этом Документе Up: Цели Previous: Цели

Запросы

Перед тем, как будет разрешен доступ к объекту, производится запрос к средствам Access Control Decision (ADF). Решение о разрешении и запрете доступа принимается в зависимости от типа запроса и цели.

Запросы RSBAC и его системные вызовы описаны в следующей таблице. Обратите пожалуйста внимание, что некоторые запросы составлены в соответствии с некоторыми условиями, например EXECUTE только из mmap(), если запрос нацелен на режим EXEC. Также, некоторые вызовы зависимы от установок конфигурации ядра, например поддержка сети в RSBAC.

Некоторые вызовы выполнены со вспомогательными функциями, например do_fork(). Эти функции также производят уведомляющий вызов rsbac_adf_set_attr() для запросов, маркированных при помощи *.

В добавок, некоторые запросы предоставляют дополнительные данные со встроенными типами атрибутов ядра. Этими атрибутами являются: A_group, A_sockaddr_p, A_signal, A_mode, A_nlink, A_switch_target, A_mod_name, A_request, A_ms_segment, A_trace_request, A_auth_add_f_cap, A_auth_remove_f_cap, A_auth_get_caplist, A_prot_bits. Ознакомьтесь пожалуйста с ними в include/rsbac/types.h.

Запрос Описание Допустимые Типы Объектов Системные вызовы и функции
ADD_TO_KERNEL Добавить модуль ядра NONE create_module(NONE), init_module(NONE)
ALTER Изменить контрольную информацию IPC IPC msgctl(IPC), shmctl(IPC)
APPEND_OPEN Открыть для дополнения FILE, DEV, IPC open(FILE,DEV)*, msgsnd(IPC)*, sendto(IPC)*, sendmsg(IPC)*
CHANGE_GROUP Сменить активную группу IPC, PROCESS, NONE setgid(PROC), setregid(PROC), setresgid(PROC), setgroups(PROC), setfsgid(NONE) (for DAC only), shmctl(IPC), msgctl(IPC)
CHANGE_OWNER Сменить владельца FILE, DIR, FIFO, IPC, PROCESS, NONE chown(FILE, DIR, FIFO), lchown(FILE, DIR, FIFO), fchown(FILE, DIR, FIFO), setuid(PROC)*, setreuid(PROC)*, setresuid(PROC)*, setfsuid(NONE) (for DAC only), shmctl(IPC), msgctl(IPC)
CHDIR Сменить рабочий каталог DIR chdir(DIR), fchdir(DIR), chroot(DIR)
CLONE Разветвить/дублировать процесс PROCESS fork(PROC)*, vfork(PROC)*, clone(PROC)*
CLOSE Закрыть открытый файл. Должно быть всегда разрешено. FILE, DIR, FIFO, DEV, IPC close(FILE, DIR, FIFO, DEV, IPC), shmdt(IPC)*, msgrcv(IPC)*, msgsnd(IPC)*, send(IPC)*, sendto(IPC)*, sendmsg(IPC)*, recv(IPC)*, recvfrom(IPC)*, recvmsg(IPC)*
CREATE Создать объект DIR (где), IPC creat(DIR, IPC)*, open(DIR, IPC)*, mknod(DIR)*, mkdir(DIR)*, symlink(DIR)*, shmget(IPC)*, msgget(IPC)*, socket(IPC)*, accept(IPC)*
DELETE Удалить объект FILE, DIR, FIFO, IPC unlink(FILE, DIR, FIFO)*, rmdir(DIR)*, msgctl(IPC)*, shmctl(IPC)*, shutdown(IPC)*. close(IPC)*
EXECUTE Выполнить файл или библиотечный код из файла или выполнить другой код (цель NONE) FILE, NONE exec(FILE)*, mmap(FILE) (EXEC mode), mprotect(FILE, NONE) (EXEC mode)
GET_PERMISSION_DATA Считать права доступа Unix (режим) FILE, DIR, FIFO access(FILE, DIR, FIFO)
GET_STATUS_DATA Получить статус (stat() подобный) FILE, DIR, FIFO, IPC, SCD open_port(SCD) (/dev/kmem etc.), open_kcore(SCD) (/proc/kcore), stat(FILE, DIR, FIFO, IPC), newstat(FILE, DIR, FIFO, IPC), lstat(FILE, DIR, FIFO, IPC), newlstat(FILE, DIR, FIFO, IPC), fstat(FILE, DIR, FIFO, IPC), newfstat(FILE, DIR, FIFO, IPC), stat64(FILE, DIR, FIFO, IPC), lstat64(FILE, DIR, FIFO, IPC), fstat64(FILE, DIR, FIFO, IPC), statfs(FILE, DIR, FIFO), fstatfs(FILE, DIR, FIFO), rsbac_stats(SCD), rsbac_check(SCD), rsbac_stats_pm(SCD), rsbac_stats_rc(SCD), rsbac_stats_acl(SCD), rsbac_log(SCD), (access to RSBAC proc-files(SCD))
LINK_HARD Жесткая ссылка FILE, DIR, FIFO link(FILE, DIR, FIFO)
MODIFY_ACCESS_DATA Изменить информацию доступа, например время, дату FILE, DIR, FIFO utimes(FILE, DIR, FIFO)
MODIFY_ATTRIBUTE Изменить значение атрибутов RSBAC Цели всех типов (специфический запрос необходимый для различных моделей безопасности)
MODIFY_PERMISSIONS_DATA Изменить права доступа Unix FILE, DIR, FIFO, SCD ioperm(SCD), iopl(SCD), chmod(FILE, DIR, FIFO) , fchmod(FILE, DIR, FIFO)
MODIFY_SYSTEM_DATA Изменить системные установки SCD stime(SCD), settimeofday(SCD), adjtimex(SCD), sethostname(SCD), setdomainname(SCD), setrlimit(SCD), syslog(SCD), sysctl(SCD), swapon(SCD), swapoff(SCD), rsbac_log(SCD)
MOUNT Смонтировать файловую систему DIR, DEV mount(DIR, DEV) (раздельные уведомления монтирования для структур данных)
READ Читать из DIR. Дополнительно: читать из других объектов DIR (Дополнительно: FILE, FIFO, DEV, IPC) read(FILE, FIFO, DEV, IPC)*, readv(FILE, FIFO, DEV, IPC)*, pread(FILE, DEV, IPC)*, readdir(DIR), open(DIR)
READ_ATTRIBUTE Считать значение атрибута RSBAC Цели всех типов (специфический запрос необходимый для различных моделей безопасности)
READ_OPEN Открыть для чтения FILE, FIFO, DEV, IPC open(FILE, FIFO, DEV, IPC)*, shmat(IPC)*, msgrcv(IPC)*, recv(IPC)*, recvfrom(IPC)*, recvmsg(IPC)*
READ_WRITE_OPEN Открыть для чтения и записи FILE, FIFO, DEV, IPC open(FILE, FIFO, DEV, IPC)*, shmat(IPC)*, bind(IPC)*, connect(IPC)*, listen(IPC)*
REMOVE_FROM_KERNEL Удалить модуль ядра NONE delete_module(NONE)
RENAME Переименовать FILE, DIR, FIFO rename(FILE, DIR, FIFO) (идентификация RSBAC при переименовании не меняется)
SEARCH Поиск в каталоге из ядра для доступа с полным именем пути DIR (встроенные функции lookup_dentry(DIR) / path_walk(DIR) / lookup_hash(DIR))
SEND_SIGNAL Послать сигнал PROCESS kill(PROC)
SHUTDOWN Останов/Перезагрузка системы NONE reboot(NONE)
SWITCH_LOG Изменить установки RSBAC NONE rsbac_adf_log_switch(NONE)
SWITCH_MODULE Включить/Выключить модуль принятия решений NONE rsbac_switch(NONE)
TERMINATE Закончить вызов процесса, для очистки атрибутов. Должно быть всегда разрешено. PROCESS exit(PROC)
TRACE Отслеживать процесс PROCESS ptrace(PROC) (архитектурозависимо)
TRUNCATE Усечь FILE open(FILE)*, truncate(FILE)*, ftruncate(FILE)*, truncate64(FILE)*, ftruncate64(FILE)*
UMOUNT Размонтировать файловую систему DIR, DEV umount(DIR, DEV) (раздельные уведомления де-монтирования для структур данных)
WRITE Запись в каталог или SCD. Используется для перемещения объектов в целевой каталог. Дополнительно: запись в файл DIR, SCD (Дополнительно: FILE, FIFO, DEV, IPC-sock) write(FILE, FIFO, IPC, DEV)*, writev(FILE, FIFO, IPC, DEV)*, pwrite(FILE, IPC, DEV)*, rename(DIR), rsbac_write(SCD)
WRITE_OPEN Открыть для записи FILE, FIFO, DEV, IPC open(FILE, FIFO, DEV, IPC)*

Обратите внимание, что некоторые модели (RC, ACL) контроля доступа имеют встроенное изменение целей NONE на SCD-цель <<other>>.


next up previous
Next: Об Этом Документе Up: Цели Previous: Цели
next up previous
Up: Цели Previous: Запросы

Об Этом Документе

Составитель:

Перевод:


next up previous
Up: Цели Previous: Запросы
next up previous
Next: Цели

Rule Set Based Access Control (RSBAC) для Linux - Цели и Запросы




next up previous
Next: Цели
next up previous
Next: Цели

Rule Set Based Access Control (RSBAC) для Linux - Цели и Запросы




next up previous
Next: Цели