Перевод: Aleksandr Blokhin и Stanislav Ievlev
Первоисточник: sisyphus.ru/srpm/Sisyphus/rsbac-doc-ru
Работа RSBAC был проверена и подтверждена со многими параметрами ядра, другими патчами и программами. Некоторые из них приведены здесь. Однако, не может быть дано никакой гарантии, что эта информация верна или эта комбинация будет работать на вашей системе в соответствии с описанием.
Обращаем ваше внимание на то, что RSBAC, по большему счету, не зависим от файловых систем и должен работать с любой локальной файловой системой (сохранение аттрибутов RSBAC для файловой системы FAT по умолчанию отключено). Этот список отображает лишь те, которые действительно были проверены.
Составитель:
Amon Ott <ao@rsbac.org>
Перевод:
Александр Блохин <sass@uustoll.ee>
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>
В демонстрационных целях в соавторстве с Simone Fischer-Hubner (http://agn-www.informatik.uni-hamburg.de/people/fischer) был создан пример простой программы. Не смотря на то, что в нем задействованы несколько моделей, наше внимание целиком сфокусировано на PM (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, используя маркеры предоставленные для программы офицером защиты данных. На этой стадии все классы объектов, задачи, цели и т.п. должны быть введены как числа, оставляя шифрование для людей.
Так как Privacy Model защищает только личные данные и системные вызовы, то для защиты других данных используется дискретный контроль доступа, реализуемый другой моделью безопасности (в рамках RSBAC дискреционный контроль доступа реализуется с использованием ACL или FF). Также, по крайней мере, идентификация и файл аутентификации /etc/shadow должны быть объявлены как личные данные с их собственным классом объекта, таким образом доступ предоставляется только авторизованным программам.
Для ограничения доступа к файлам в этом примере может быть использован Functional Control (данная модель считается устаревшей так как ее возможности перекрываются другим модулем (RC)). В этой модели системные объекты и объекты категорий безопасности доступны только офицерам безопасности (не обязательно, что бы это были одни и те же лица, что и в PM) и администраторам. Если должно предотвращаться только неавторизованное изменение, например в /etc/passwd, то для этих целей должно быть достаточно модели Security Information Modification с ее атрибутом data type (данная модель также считается устаревшей так как ее возможности перекрываются (RC)).
Дополнительно, для конфиденциальности деловой информации, должна использоваться Mandatory Model (мандатный доступ - модуль MAC).
Прохождение пациента через медицинский центр характеризуется следующими стадиями:
Составители:
Amon Ott <ao@rsbac.org>
Simone Fisher-Hubner <simone@dsv.su.se>
Перевод:
Александр Блохин <sass@uustoll.ee>
Этот пример описан в отдельном документе - Пример Privacy Model .
Составители:
Amon Ott <ao@rsbac.org>
Simone Fisher-Hubner <simone@dsv.su.se>
Перевод:
Александр Блохин <sass@uustoll.ee>
Защита всех исполняемых файлов, например в /sbin, от подмены
Исходные тексты RSBAC разбиты на три части, находящиеся по адресу http://www.rsbac.org/code/, которые устанавливаются отдельно:
Для новичков также существует хорошая документация RSBAC for Beginners, по адресу http://linux.ru.net/inger/RSBAC-DOC.html
Lilo (Milo на alpha) позволяет при загрузке передавать ядру дополнительные параметры. Большинство из них по умолчанию задает отладочный режим работы, который может быть изменен позднее через syscall или proc-интерфейс. RSBAC-система акцептирует следующие, не являющиеся структурами данных, принудительные или связанные с принятием решения отладочные или вспомогательные параметры (для дополнительной информации смотрите README-kernparm):
Административный инструментарий из файла 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 для получения большего размера изображения.
Общее администрирование осуществляется средствами командной строки или при помощи диалоговых меню. Напрямую, к RSBAC-файлам обращаться нельзя. Многие параметры могут быть проконтролированы и установлены во время работы, если это задействовано в конфигурации ядра, через proc-интерфейс в proc/rsbac-info (смотри README-proc в Documentation/rsbac). Все средства командной строки используют новые системные вызовы, предоставляемые пакетом RSBAC, и все проверки доступа делаются в пределах ядра. Однако, эти инструменты делают некоторую проверку здравомыслия.
Каждый инструмент печатает короткую справку, если он вызывается с недостаточными параметрами. В настоящее время предоставляются следующие инструменты:
RC-модуль администрируется при помощи атрибутов и определений роли и типа с использованием средств администрации RC.
ACL-модуль администрируется через установки попечителя и маски для субъектов и объектов различных типов. Они устанавливаются при помощи acl_grant и acl_mask, административного инструментария ACL , и считываются с acl_tlist и acl_rights. Никакие общие атрибуты не применяются. Рекомендуются ACL-меню.
Атрибуты, так же как и содержащие их типы данных для системных вызовов (смотри
types.h, pm_types.h и rc_types.h), определены и описаны на странице описания
моделей и в руководстве пользователя syscall. Точное описание
синтаксиса и кодов для числовых значений атрибутов включены в относящуюся к
ним справку в инструментарии (вызов без параметров).
Пока этот модуль активен, общие средства (и системные вызовы) для установки атрибутов не действуют для любого подходящего отдельного атрибута. Напротив, все администрирование выполняется средствами rsbac_pm, который является просто интерфейсом для системных rsbac_pm-вызовов основанных на бюллетенях. Эта программа также акцептирует имена как значения, например security_officer для функции set_role. К сожалению все еще не существует меню-ориентированного инструментария - все еще ищем добровольцев...
Поскольку само назначение PM-ролей основанное на бюллетенях, выполненное офицером защиты данных, используется офицером безопасности, эти PM-роли, назначенные при помощи атрибута pm_role, должны иметь два различных пользователя. Это автоматически делается при установке для пользователя 400 (офицер защиты, как системная роль) и 401 (офицер защиты данных). Если этого не произошло, загрузитесь с ремонтным ядром и вызовите
attr_set_up USER pm_role security_officer 400
attr_set_up USER pm_role data_protection_officer 401
Администрирование 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 1 400.
Для администрирования ACL предназначены средства командной строки acl_rights,
acl_grant, acl_mask и acl_tlist. Каждый кто знаком с администрированием Netware
3.xx (tm) не найдет разницы после просмотра описания моделей на странице .
Всем остальным крайне желательно изучить описание моделей перед внесением каких-либо
изменений.
Также имеются два интерактивных средства, rsbac_acl_menu и rsbac_acl_group_menu, которые могут облегчить жизнь.
В комплект для администрирования также включены некоторые другие программы, которые описаны здесь. Конечно, они также имеют ограничения по контролю доступа.
Резервное копирование выполняется в два прохода: Резервным копированием атрибутов и резервным копированием файлов и каталогов. Для выполнения резервного копирования вы должны сначала выключить все активные модули, если вы сконфигурировали ядро без возможности отключения, то вы должны перезагрузиться с ремонтным ядром. По очевидным причинам перед отключением контроля доступа, рекомендуется ``опустить'' все сетевые интерфейсы.
После этого вы можете использовать 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-группы восстанавливаются их настоящими владельцами, иначе их владельцем станет пользователь выполняющий сценарий восстановления Разумеется, восстанавливающий пользователь позднее может передать права владения.
В демонстрационных целях вместе с Simone Fischer-Hubner (http://agn-www.informatik.uni-hamburg.de/people/fischer)
были созданы программные примеры простой Privacy Model (PM) .
Хотя и используются некоторые модули, наше внимание сфокусировано на моделях
секретности, являющихся наиболее полными и в то же время мощными. Другие модули
используются в специальных целях.
Некоторые другие примеры находятся в документе Примеры .
Составитель:
Amon Ott <ao@rsbac.org>
Перевод:
Александр Блохин <sass@uustoll.ee>
Для установки вы должны иметь развернутое дерево исходных текстов поддерживаемого ядра. Исходные тексты ядра доступны на 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 и объектные файлы.
После этого, 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! Уверен, что прежде чем начать вы произвели резервное копирование, не так ли?
Вы можете просто развернуть 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 предупреждение об этом.
Обратите внимание. Изменения были в патчах для следующих версий:
Внимание: От версии к версии 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 отмечена как 'нежелательная' и позднее может быть удалена.
При первой загрузке вашего нового RSBAC ядра с AUTH-моделью не забудьте передать ядру параметр rsbac_auth_enable_login, например в приглашении lilo:
В процессе загрузки вы увидете некоторые сообщения 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 и используйте значения их атрибутов.
Если ваша система стала недоступна, или вы хотите произвести резервное копирование без ограничений доступа, вы должны создать ремонтное ядро. Весь контроль доступа в этом ядре находится в незадействованном состоянии, так что все пользователи могут менять установки без ограничений.
С 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 имя_файла.
Если вы обновили свое ядро и структура данных для списка типов изменилась, то
будет выведено предупредительное сообщение. Данные от старой версии будут конвертированы
и загрузка пройдет как обычно. Однако, данные от очень старых версий или в поврежденных
файлах могут быть не читаемы, тогда устройство или список получит статус 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, что окажет тот же самый эффект.
Access Control Decision Facility (ADF) содержит мощную систему регистрации событий. Имеется возможность указать события, которые будут зарегистрированы в зависимости от типа запроса, пользователя, выполняемого и целевого объекта (файла, FIFO, каталога или устройства). Некоторые из этих особенностей должны быть задействованы в конфигурации ядра.
Регистрируемыми событиями являются запросы, идентификаторы процессов, названия программ, идентификаторы реальных пользователей или псевдонимов, типы объектов, идентификаторы объектов, типы атрибутов, значения атрибутов, решения ADF и названия модулей принявших эти решения.
Для каждого регистрируемого ключа уровень регистрации может быть установлен индивидуально, в зависимости от типа запроса.
Как и любой доступ, доступ к настройкам регистрации событий является контролируемым, каждая модель может реализовать свою схему контроля доступа для собственной защиты.
Всякий раз, когда запрос пробежал все модули, диспетчер решения проходит следующий алгоритм, чтобы решить, должен ли быть зарегистрирован запрос. Обратите пожалуйста внимание, что протоколирование имеет место, если по крайней мере на одном из этих шагов будет принято решение, что протоколирование необходимо. Так что решение 'протокол' прерывает алгоритм.
1. Если включена индивидуальная регистрация действий пользователя и пользовательским уровнем регистрации для запроса является
Перевод: Александр Блохин <sass@uustoll.ee>
Access Control Decision Facility (ADF) содержит мощную систему регистрации событий. Имеется возможность указать события, которые будут зарегистрированы в зависимости от типа запроса, пользователя, выполняемого и целевого объекта (файла, FIFO, каталога или устройства). Некоторые из этих особенностей должны быть задействованы в конфигурации ядра.
Регистрируемыми событиями являются запросы, идентификаторы процессов, названия программ, идентификаторы реальных пользователей или псевдонимов, типы объектов, идентификаторы объектов, типы атрибутов, значения атрибутов, решения ADF и названия модулей принявших эти решения.
Для каждого регистрируемого ключа уровень регистрации может быть установлен индивидуально, в зависимости от типа запроса.
Как и любой доступ, доступ к настройкам регистрации событий является контролируемым, каждая модель может реализовать свою схему контроля доступа для собственной защиты.
Всякий раз, когда запрос пробежал все модули, диспетчер решения проходит следующий алгоритм, чтобы решить, должен ли быть зарегистрирован запрос. Обратите пожалуйста внимание, что протоколирование имеет место, если по крайней мере на одном из этих шагов будет принято решение, что протоколирование необходимо. Так что решение 'протокол' прерывает алгоритм.
1. Если включена индивидуальная регистрация действий пользователя и пользовательским уровнем регистрации для запроса является
Перевод: Александр Блохин <sass@uustoll.ee>
В настоящий момент в RSBAC входят следующие модели:
Модель обязательного контроля доступа используемая в 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 определяет четыре модели доступа:
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 показывает суммарные состояния контроля доступа. S означает субъект, O объект, Od объект каталога и >= и = стоит для обозначения доминирует и имеет тот-же уровень. Запись и чтение на каталогах подразумевает доступ к объектам без возможности их открытия.
Модель 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.
Станислав Иевлев и я (Amon Ott, прим.переводчика) добавили параметр MAC называемый MAC-Light для упрощения использования модуля MAC. Вот изменения:
Эта модель была снята с повестки дня для RSBAC и не будет реализована пока кто-нибудь не убедит в ее необходимости.
Простейшая ролевая модель назначает каждому пользователю роль, например главный пользователь, офицер безопасности или системный администратор. Каждый объект получает категорию, например главный, секретный или системный объект.
Офицер безопасности определяет какие роли являются совместимыми с какими категориями объекта или, другими словами, при каких ролях к каким категориям объектов пользователи имеют доступ. Эти установки предписывает система безопасности.
Признак object_category для файла/каталога/fifo может быть унаследован от родительского каталога.
Функциональный контроль в простой версии, которая реализована в RSBAC, может защищать только системные данные и данные относящиеся к системе, но это уже требует разделения обязанностей между двумя специальными ролями. Дальнейший переход к более гибким ролям превратили бы это в более строгую модель. Без разграничения между различными моделями доступа эта модель может быть использована только как часть комбинированной системы.
FC может быть полностью выражен RC моделью, так что это устарело. Установки RC, используемые по умолчанию, подобны этой модели.
Эта ролевая модель защищает данные типа информации защиты. Доступ на запись к этим объектам могут получить только пользователи с ролью офицера безопасности.
Признак data_type для файла/каталога может быть унаследован от родительского каталога.
Эта модель может быть использована как функциональный контроль только в комбинации с другими. Однако, информация, относящаяся к безопасности, может быть защищена от вмешательства системного администратора, что превышает возможности контроля доступа в стиле Unix.
SIM может быть полностью выражен RC моделью, так что это добро устарело.
Эта модель была представлена на 17ой Национальной Конференции Компьютерной Безопасности в Балтиморе, США, в 1994 году ее разработчиком Simone Fischer-Hubner. Это следствие из правил Федерального Немецкого Закона о Секретности и директивы ЕС о безопасности.
Модель и ее реализация в RSBAC детально описаны в наших отчетах по
Конференции NISS 98 .
Модель сфокусирована на безопасности. Конфиденциальность, целостность и доступность представлены для личных данных и процедур по определению необходимых доступов.
Контрольные системные данные, такие как глобальные настройки или данные аутентификации могут быть защищены только путем объявления их личными данными. Если для каких-то данных это сделать невозможно, то они не могут быть защищены.
Эта модель может быть использована для хранения и обработки персональных данных. Для защиты системных данных без администрирования наверху, рассматривая их как персональные данные, должна использоваться другая модель, например FC, SIM, RC или ACL.
Это не настоящая модель контроля доступа, но предпочтительнее системной модели защиты от нежелательного программного кода. Выполнение, чтение и передача файлов инфицированных нежелательным программным кодом может быть предотвращена.
Если данные, особенно программы, перемещены из других систем, то во избежание широкого распространения инфекции должна быть использована эта модель. Однако, определен может быть только известный алгоритму сканнера инфицированный код. На Linux это вирус bliss, варианты A и B, и некоторые вирусы DOS. Платформозависимые макро- и ява вирусы будут включены позднее.
В настоящий момент это только рабочая демонстрационная модель, поскольку пока обнаружено слишком мало вирусов. Однако, при желании, довольно просто добавить большее количество строк поиска. Просто спросите в листе рассылки как это сделать. :)
Для дополнительной информации смотрите нашу документацию о Подходе к Обнаруженю Встроенного Вредоносного Программного Кода и Его Предупреждению
для Третьего Скандинавского Симпозиума по Безопасным IT Системам (Nordsec'98).
Эта модель определяет некоторые флаги доступа для файлов, 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 не может быть перемещен или замещен для подделки других домашних каталогов для большинства пользователей.
Внимание: Это - описание более старой версии RC. Пожалуйста, для последних
версий RSBAC, обращайтесь к новому руководству !
Это мощная и гибкая ролевая модель. Она определяет 64 RC-типа для объекта каждого типа (Файл/Каталог, Устройство, Межпроцессное Взаимодействие, Данные Системного Контроля) и 64 RC-роли для доступа к ним. Модуль RC был добавлен в RSBAC в версии 1.0.8.
Пожалуйста, также смотрите описание модели RC в RC-Paper .
Каждое вхождение роли имеет следующие поля:
Поле Вхождения Роли | Типы/Значения | Описание |
name | строка из 15 знаков | Имя роли |
role_comp | 64 битный вектор | Совместимые роли (1 Бит на роль) = процесс ролей могут изменяться на без chown (setuid) |
type_comp_fd | 64 битный вектор | Совместимые типы файла/каталога (1 Бит на тип) |
type_comp_dev | 64 битный вектор | Совместимые типы устройств |
type_comp_process | 64 битный вектор | Совместимые типы процессов |
type_comp_ipc | 64 битный вектор | Совместимые типы IPC |
type_comp_scd | 64 битный вектор | Совместимые типы SCD |
admin_type | нету, системный или ролевой администратор | Роль для администрирования RC роли/типа |
def_fd_create_type | Номер типа файла/каталога или специальное значение | Тип новых файлов/каталогов |
def_process_create_type | Номер типа процесса или специальное значение | Тип новых (ответвленных/дублированных) процессов |
def_process_chown_type | Номер типа процесса или специальное значение | Тип процессов после chown (setuid) |
def_process_execute_type | Номер типа процесса или специальное значение | Тип процессов после выполнения (запуск новой программы) |
def_ipc_create_type | Номер типа IPC или специальный флаг | Тип нового канала IPC |
Запись admin_type обозначает права администратора: none = нету, system admin = только чтение, role admin = полные. они не дают никаких других прав доступа, это сделано только для совместимости с окружением.
Типы вхождений имеют поле имени (длиной до 15 знаков). Только тип вхождения файл/каталог имеет дополнительную переменную type_fd_need_secdel, что обозначает безопасное удаление/усечение файлов этого типа.
SCD типы являются фиксированными и представляют одну область системных данных каждый. Они также используются для административных прав, таких как добавление модулей или установка системного времени. Совместимость SCD означает доступность средств SCD.
Каждый объект, не говоря уже об объектах пользователя, для обозначения своего типа получает атрибут rc_type. Для файлов и каталогов это поле может содержать специальное значение type_inherit_parent для обозначения наследственности атрибута.
Пользовательское вхождение получает атрибут rc_def_role, для определения начальной роли процесса после каждого CHOWN (setuid).
Вхождения процесса также имеют rc_role для текущей роли.
Вхождения Файл/Каталог имеют поле rc_force_role для обозначения форсированной роли, если этот файл выполнен. Этот механизм работает схоже с полями setuid или setgid в файловой системе Unix. Форсированная роль также может иметь одно из специальных значений.
Специальными значениями, о которых упоминалось выше, являются следующие:
Специальное Значение Роли | Значение |
role_inherit_user | rc_def_role пользователя (владельца процесса) |
role_inherit_process | использование текущей rc_role процесса (удержание роли) |
role_inherit_parent | использование текущей rc_role родительского каталога или процесса |
Тип Специального Значения | Значение |
type_inherit_process | использование текущей rc_role процесса (удержание роли) |
type_inherit_parent | использование текущей rc_role родительского каталога или процесса |
type_inherit_parent | создание процесса/IPC не разрешено |
type_no_execute | выполнение другой программы не разрешено |
type_use_new_role_def_create | для процесса chown (setuid): использовать def_process_create_type новой роли |
Если запущено без определений ролей, то устанавливаются три предопределенных роли: General User (0), Role Admin (1) и System Admin (2). Установки для предопределенных ролей берутся из жестко встроенных установок в модуле FC.
Если запущено без определения типов, то устанавливается по одному типу на объект. Это тип по умолчанию General, который также используется как значение по умолчанию для атрибутов всех типов.
В RSBAC, как правило, пользователь root (0) имеет rc_def_role 2 и пользователь 400 имеет rc_def_role 1, как предопределенное значение в useraci по умолчанию, содержащемся в пакете инструментария администратора.
Пожалуйста помните: Предопределенные роли это нормальные роли, созданные для того, чтобы позволить вам начать. Они могут быть изменены как любые другие роли! Вы можете запросто себя заблокировать, если вы измените их без достаточного понимания того, что вы делаете.
Итак, режим обслуживания позволит вам изменять роли, если вы включили поддержку режима обслуживания для данных RC-правил в конфигурации ядра.
В целях безопасности тестируйте вашу конфигурацию с различным количеством ролей и используйте, при необходимости, rc_copy_role чтобы их копировать.
Более старая модель RC была сильно изменена. Она все еще определяет 64 RC-типа для каждого объекта (Файл/Каталог, Устройство, Процесс, Межпроцессное Взаимодействие, Данные Контроля Системы) и до 64 RC-ролей для доступа к ним. Оригинальный модуль RC был добавлен в RSBAC версии 1.0.8.
RC - это ролевая модель: Каждый пользователь имеет роль по умолчанию, которая передается по наследству всем его процессам. Доступ к объектам определенных типов, основанный на текущей роли, разрешен или запрещен. Роль меняется с изменением владельца процесса, процессом через системный вызов (разрешены только ``подходящие'' роли) или исполнением специально обозначенного выполняемого (используя force_role, необходимо быть не ``подходящим'').
Создание нового процесса является особым случаем в каждой модели контроля доступа. Здесь, каждая роль имеет вхождения для типов новых объектов, так же как вхождения для типа, регулирующего поведение на исполнение и изменение владельца процесса. Дополнительно, все эти вхождения имеют специальные значения, типа "no_create", которые отвергают подобные запросы.
Также, пожалуйста, смотрите описание модели RC в RC-Paper .
Каждое вхождение роли имеет следующие поля:
Поле Вхождения Роли | Тип/Значение | Описание |
имя | строка из 15 знаков | Имя роли |
role_comp | 64 битный вектор | Подходящие роли (по 1 Биту на роль) = процессы ролей могут изменяться без chown (setuid) |
type_comp_fd | Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) | Подходящие типы файлов/каталогов для запрошенных типов (1 Бит на тип и запрос) = значение True/False, к типу которого можно обращаться по запросу |
type_comp_dev | Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) | Подходящие для запрошенных типов типы устройств (1 Бит на тип и запрос) |
type_comp_process | Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) | Подходящие для запрошенных типов типы процессов (1 Бит на тип и запрос) |
type_comp_ipc | Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) | Подходящие для запрошенных типов типы процессов (1 Бит на тип и запрос) |
type_comp_scd | Множество 64 векторов из 64 частиц каждый (64x64 Битная Матрица) | Подходящие для запрошенных типов типы SCD (1 Бит на тип и запрос) |
admin_type | нету, системный или ролевой администратор | Роль для администрирования роли/типа RC |
def_fd_create_type | Номер типа file/dir или специальное значение | Тип новых файлов/каталогов (для запрета создания используйте no_create, для выбранного типа требуются права CREATE) |
def_process_create_type | Номер типа процесса или специальное значение | Тип новых (ответвленных/дублированных) процессов (для запрета создания используйте no_create, для выбранного типа требуются права CREATE) |
def_process_chown_type | Номер типа процесса или специальное значение | Тип процесса после chown (setuid) (для запрета создания используйте no_chown) |
def_process_execute_type | Номер типа процесса или специальное значение | Тип процесса после выполнения (старт новой программы) (для запрета создания используйте no_execute) |
def_ipc_create_type | Номер типа IPC или специальный флаг | Типы новых каналов IPC (для запрета создания используйте no_create, для выбранного типа требуются права CREATE) |
Вхождение admin_type указывает административные права RC для ролей, типов и специфических для RC атрибутов: none = нет доступа, системный администратор = только чтение, ролевой администратор = полный доступ. Они не дают никаких прав доступа объекту, это делается только подходящими установками.
Типы вхождений имеют поля имен (строка из 15 знаков). Только вхождения типа файл/каталог имеют дополнительное значение переменной type_fd_need_secdel, которые указывает на необходимость безопасного удаления/усечения файлов этого типа.
Типы SCD являются фиксированными и представляют одну область доступных системных данных каждый. Они также используются для административных прав, в данный момент только для auth_administration. Совместимость SCD означает доступность средств SCD. Вдобавок, специальный объект SCD 'other' используется для контроля целевых запросов типа NONE.
Каждая отдельный объект со стороны пользовательских объектов для обозначения своего типа получает атрибут rc_type. Для файлов и каталогов это поле должно содержать специальное значение type_inherit_from от родительского для наследования сигнала атрибута.
Пользовательские вхождения получают атрибут rc_def_role, который используется для указания начальной роли процесса после каждого CHOWN (setuid).
Вхождения процесса также имеют rc_role для текущей роли и поле rc_force_role для удержания значения rc_force_role выполненной программы.
Вхождения Файл/Каталог имеют поле rc_force_role для указания форсированной роли, если этот фаул выполнен. Этот механизм работает аналогично полям setuid или setgid в файловой системе Unix. Форсированная роль может также иметь одно из специальных значений (см. ниже). Значение форсированной роли копируется в атрибуты процесса для дальнейшего использования при запросах CHOWN.
Специальными значениями, упомянутыми ранее, являются следующие:
Специальное Значение Роли | Предназначение |
role_inherit_user | использование пользовательских rc_def_role при CHOWN и EXECUTE (роль, форсированная по умолчанию с 1.0.9а-pre2) |
role_inherit_process | удержание текущей rc_role процесса при CHOWN и EXECUTE |
role_inherit_parent | наследование значения от родительского объекта, например родительского DIR |
role_inherit_up_mixed | удержание текущей rc_role процесса при EXECUTE, но с использованием новой rc_def_role владельца процесса при CHOWN (роль, форсированная по умолчанию с 1.0.9а-pre3) |
Тип Специального Значения | Предназначение |
type_inherit_process | использование текущей rc_type процесса (удержать тип) |
type_inherit_parent | использование текущего rc_type родительского каталога или процесса |
type_no_create | создание процесса/файла/каталога/IPC не разрешено |
type_no_execute | выполнение других программ не разрешено |
type_no_chown | изменение владельца процесса не разрешено |
type_use_new_role_def_create | для chown (setuid) процесса: использовать def_process_create_type новой роли |
Если запущено без определений роли, устанавливаются три предопределенных роли: General User (0), Role Admin (1) and System Admin (2). Получаются три предопределенных установки ролей из жестко встроенных установок в модуле FC.
Если запущено без установок типа, то устанавливаются по три типа на объект. Это тип по умолчанию ``General'' (0), который также используется как значение по умолчанию для всех атрибутов типа, тип ``Security'' (1) и тип ``System'' (2). На самом деле только ``General'' используется в установках по умолчанию, но примеры пригодности установлены для всех типов.
Как обычно в RSBAC, пользователь root имеет rc_def_role 2 и пользователь 400 имеет rc_def_role 1, как предустановленное значение в ACI установках пользователя по умолчанию.
Пожалуйста, помните: Предопределенные роли - это роли, созданные для того, чтобы вы могли начать. Они могут быть изменены как все другие роли! Вы можете запросто заблокировать себя, если измените их без достаточного понимания происходящего. Наиболее подходящий способ это, скопировав роль, производить изменения в новой роли.
Однако, режим обслуживания позволит вам изменять роли, если вы включите поддержку для обслуживания правил RC в конфигурации ядра.
В целях безопасности, проверяйте вашу конфигурацию с разным количеством ролей и используйте, при необходимости, rc_copy_role для их копирования.
Для соблюдения правила наименьшей привилегированности, вы можете сделать роль пользователя 0 по умолчанию фиктивной и устанавливать роль для каждого пользователя непосредственно. Таким образом, добавляя новых пользователей, никто ничего не получит.
Расширенное Администрирование с разделением обязанностей (с 1.0.9а-pre2 и далее)
Новейшие версии RC содержат сложную модель разделения обязанностей. Для этого были сделаны следующие дополнения:
ASSIGN: Назначить этот тип объекту. Вам также необходим MODIFY_ATTRIBUTE на объектах старого типа.
ACCESS_CONTROL: Изменение нормальных (старых) прав доступа для этого типа для ваших администрированных ролей.
SUPERVISOR: Изменение этих новых специальных прав на этот тип для ваших администрированных ролей.
Если нет роли, имеющей право SUPERVISOR на тип, то разделение всегда зафиксировано (снова, пока не перезагружено Maint ядро, или кто-то все еще имеет административный тип Role-Admin старого типа).
Этот модуль может быть рассмотрен как модуль поддержки для всех остальных модулей. Он ограничивает смену владельца для процессов (CHANGE_OWNER) на объектах процессов (setuid): запрос разрешен только если процесс имеет установленный флаг auth_may_setuid или в его наборе способностей находится целевой ID пользователя. Флаг auth_may_setuid и набор способностей наследуются при выполнении от программного файла.
Другими словами: Ни для какого процесса выполняющего любую программу не может быть разрешен setuid() вариант системного вызова, пока процесс (например наследованный от программного файла) имеет установленный флаг auth_may_setuid или возможность AUTH для целевого uid.
Возможности программных файлов могут быть установлены, если всем модулям разрешен запрос MODIFY_ATTRIBUTE для A_auth_add_f_cap или A_auth_remove_f_cap. Возможности процесса могут быть добавлены только другими процессами, которые имеет установленный флаг auth_may_set_cap, который также унаследован от их выполненного файла.
Таким образом возможно осуществление процесса аутентификации базирующееся на демоне, также как ограничение системных демонов набором пользовательских ID.
ПРЕДУПРЕЖДЕНИЕ: Если позволяется иметь без программы логина auth_may_setuid или набор возможностей и без серверного процесса устанавливающего возможности, то вы не сможете войти в систему! Используйте параметр ядра rsbac_auth_enable_login в критических случаях или при первой загрузке установите auth_may_setuid для /bin/login.
При задействованном AUTH, таким системным демонам, с setuid нормальной пользовательской учетной записи, как portmap, mysql или что нибудь еще, требуется явная возможность так делать. И они должны использовать только те uid которые вы разрешите.
Все Процессы имеют два auth флага: auth_may_setuid и auth_may_set_cap с вышеупомянутыми значениями. Они унаследованы всеми детскими процессами.
Все файлы имеют те же самые два флага, которые заменяют таковые процесса при выполнении файла.
Файлы и процессы также имеют наборы возможностей с теми же самыми правилами наследования. Добавление к и при удалении от наборов возможностей ограничено в соответствии с различными схемами контроля доступа процессов и файлов: заголовки процесса могут быть установлены любым процессом, который имеет набор auth_may_set_flag, кто бы не был владельцем процесса. Флаги файла установлены от имени пользователей для любой программы.
До версии 1.0.9а, наборы возможностей файлов могли иметь специальное значение 65533 (UID -3), которое замещалось владельцем процесса во время копирования набора (время выполнения). Эти процессы могут вернуться назад к оригинальному ID пользователя посте его изменения. Это значение было изменено на 4294967292 (снова -3) в 1.0.9b, которое поддерживает 32 Битный ID пользователя.
Сначала не разрешено ничего. Таким образом Вы должны позволить логин администратору, который может делать все необходимое. Это может быть сделано при обслуживании ядра, установкой подходящих значений для всех задействованных файлов программы.
Как ссылку, вы можете использовать параметр ядра rsbac_auth_enable_login, который устанавливает auth_may_setuid (все права для изменения владельца процесса) для /bin/login. Это поведение усилено в структуре данных модуля AUTH.
AUTH только ограничивает его администрацию, если это позволено в конфигурации ядра. Администрация разрешена пользователю с system_role security_officer, и все задействованные атрибуты защищены.
В дальнейшем каждый модуль может ограничить администрацию AUTH, если это зависит от надлежащей аутентификации. Для большей информации смотри страницы справки меню конфигурации.
Администрирование в основном основано на атрибутах файла и процесса
и наборах возможностей обозначенных выше. Детали смотри в Руководстве по Установке и Администрированию .
Списки Контроля Доступа определяют какой субъект (пользователь, роль RC или группа ACL) к какому объекту (какого типа объекта) может иметь доступ с каким запросом (обычно запросами RSBAC и особенностями ACL).
Если здесь нет ACL вхождения для субъекта к объекту, то права к родительскому объекту унаследованы. Наследственность может быть ограничена масками наследственности.
Наверху иерархии наследственности находится значение ACL по умолчанию для каждого типа объекта (ФАЙЛ, КАТАЛОГ, ...).
Для изменения значения ACL объекта вам необходимы специальные права Контроля Доступа для этого объекта. Специальные права Forward позволяют дать права, которыми ва обладаете, кому-нибудь еще, но вы не сможете их в последствии отменить.
Специальные права Supervisor включают все остальные права, которые никогда не могут быть замаскированы (если не разрешено в конфигурации ядра) и могут быть установлены только пользователями имеющими их. Эти права установлены для пользователя 400 в его конфигурации ACL по умолчанию, которые не могут быть прочитаны с диска во врем работы, например во время новой установки.
Поддерживаются все типы объекта. Только объекты IPC, USER и PROCESS имеют общий ACL по умолчанию, который всегда наследуется всеми объектами этого типа - эти объекты слишком недолговечны для администрирования полезных индивидуальных ACL.
От версии 1.0.9a, есть неизменная ACL группа Everyone (группа 0), которая по определению содержит всех легальных пользователей, таких как группы определенные пользователем.
Групповой менеджмент позволяет каждому пользователю определять глобальные и частные группы без ограничений. Глобальные группы могут быть использованы любым пользователем, приватные только владельцем группы. Также только владельцу группы позволено добавлять или удалять членов группы или изменять установки группы название, владелец и тип. Так как владелец может быть изменен, группа является передаваемой (таким образом ее можно сделать недоступной для настоящего владельца). Эта особенность могла бы стать дополнительной в будущих выпусках потому, что это может использоваться для нападений.
Права группы могут быть добавлены к правам пользователя и роли. Так как нет глобального группового администратора, каждый пользователь может выполнять работу по обслуживанию благоразумной структуры группы, например пользователь secoff.
Только упоминание: Пособия к другим сетевым PC системам могут быть не лишними ...;-)
Составитель:
Перевод:
Модель Bell и La Padula описывает доступ активных объектов, называемых субъектами, к пассивным объектам, называемых объектами. Один объект, в зависимости от типа доступа, может представать в обеих ролях.
Различия между доступом на чтение и запись, могут различаться по четырем способам доступа: ни на чтение ни на запись (execute, e), только чтение (read, r), только запись (append, a) и чтение-запись (write, w). Набор всех типов доступа назван А.
Каждое обращение субъекта Si к объекту Oj способом x описывается таким набором как (Si,Oj,x). Вся эта троица вместе составляет набор текущих обращений b .
Объекты структурированы по принципу Отец-Сын и образуют иерархию H в одном, или более, независимых деревьях.
Все авторизованные обращения всех субъектов ко всем объектам содержатся в матрице M. Таким образом каждая ячейка Mij из M содержит поднабор из A с авторизованными обращениями от Si к Oj.
Степень защиты задается парой (Уровень Доступа, Вектор (множество) Категорий). Уровень доступа это значение происходящее из иерархии, например: публично, конфиденциально, секретно, сверхсекретно. Категория формально назначается рабочему окружению.
Один объект со степенью защиты (S1,C1) доминирует над другим объектом (S2,C2), если S1 >= S2 и C1 превосходит С2. Объект, доминирующий над всеми другими объектами, образует отношение доминирования D.
Назначение степени защиты для субъектов и объектов. Функция классификации F задается кортежем (fS,fO,fC) функций назначения степени защиты, где fS(Si) является максимальной степенью защиты для субъекта Si, fO(Oj) является степенью защиты объекта Oj и fC(Si) является текущей степенью защиты субъекта Si. Таким образом различаются максимальная и текущая степени защиты субъектов.
Для всех Si fS(Si) всегда должно доминировать над fC(Si).
Состояние модели z задается как набор из четырех элементов (b, M, F, H) таким образом система представляется в виде последовательности состояний с некоторым начальным состоянием z0.
Первое используемое свойство это простое свойство защиты - не считываемость. Оно состоит в том, что субъект Si может иметь право доступа на чтение к объекту Oj ((Si,Oj,r) или (Si,Oj,w) это текущий доступ), если Si доминирует над Oj.
Схема 1: Незаконный информационный поток в модели Bell-La Padula.
Во избежание копирования злоумышленником объекта в уровень с меньшей степенью защиты добавляется еще одно свойство - ``*-property'' (не списываемость). Это свойство означает: если субъект Si имеет доступ на чтение к объекту O1 и доступ на запись к объекту O2, тогда O2 должно доминировать над O1 (O1 имеет более низкий уровень защиты, чем O2). Таким образом информационный поток ограничен свыше.
Поскольку строгое следование даному правилу значительно уменьшило бы применяемость системы, некоторые субъекты могут быть отмечены как доверенные субъекты без ограничений.
Контроль доступа матрицы М авторизованного доступа субъектов к объектам называется дискреционном контролем доступа, эта особенность защиты называется ``ds-property''. Текущий доступ должен всегда быть в наборе авторизованного доступа в его матричной ячейке.
Свойства и уровни защиты должны быть принудительно заданы системе. Каждое свойство добавляется к другим и никогда не понижает защиту системы. Состояние, удовлетворяющее всем этим требованиям, называется безопасным.
Три свойства служат директивой для следующих правил управления доступом при принятии решения:
Текущий допуск (Si,Oj,x) предоставлен только в том случае, если выполнены следующие условия:
1. ss-property: Si доминирует над Oj, если x = r или x = w (x заключает в себе доступ на чтение).
2. *-property: Si является доверенным либо :
2.1. Oj доминирует над текущим уровнем Si, если режим = a
2.2. уровень Oj равен текущему уровню Si, если режим = w
2.3. текущий уровень Si доминирует над уровнем Oj, если режим = r
3. x-property: x находится в ячейке Mij авторизованных обращений матрицы M
Для использования определенной системы безопасности необходимо определение функций перехода. Эти функции вероятно должны переводить одно состояние защиты в другое состояние защиты, в соответствии с правилами принятия решений. Так индукция может использоваться для подтверждения защищенности любого возможного состояния.
Полный набор этих функций следующий:
release-access(): удалить значение кортежа из набора b
rescind-access-permission(): удалить режим доступа из ячейки M
change-current-level()
delete-object-group(): удалить объект вместе с под-объектами из дерева
Модель Белла и Ла-Падулы касается только аспектов конфиденциальности. Целостность, пригодность и безопасность данных при этом не защищены. Например, субъект на самом низком уровне безопасности может удалять все данные во всех его категориях, если они предусмотрительно не защищены. Атаки подобные этой так-же могут случаться без пользовательской осведомленности, только подумайте о вирусах или ошибках. Управляемый контроль доступа особенно подвержен атакам троянцев.
Концепция доверенных субъектов, которые могут только быть осуществлены как пользователи или пользовательские процессы, ведет к возможности нападения в дальнейшем при помощи пользовательских счетов высокого уровня.
Эта модель может быть использована без дополнительной защиты, если конечной целью является достижение конфиденциальности или же данные могут быть легко восстановлены.
Технологии приватности в последнее время становятся всё более и более актуальны, так как индивидуальная секретность в Глобальном Информационном Сообществе подвержена опасности. В этом документе описывается обновлённая версия формальной модели приватности, которая может быть использована для технического внедрения законодательных требований секретности. Этот документ демонстрирует, как может быть определена и реализована политика приватности в соответствии с Generalized Framework for Access Control (GFAC).
При продвижении к Глобальному Информационному Сообществу, индивидуальная секретность подвергается риску (см. [Fischer-Hubner 1997г]). Директива ЕС по защите информации, также как и законы о секретности многих западных государств требует, чтобы при сборе или обработке персональной информации гарантировались основные принципы секретности, типа:
Однако, помимо защиты приватности пользователей, также необходимы технологии, расширяющие секретность для защиты субъектов данных (так называемых 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]).
Так как всем уместным, с точки зрения безопасности, обращениям в системах Unix требуются системные вызовы к ядру, AEF реализуется дополнением всех уместных системных вызовов ADF-запросами и сообщениями уведомляющего характера. Для каждого системного вызова используется один ADF-запрос, обращенный к его функциональности, который, при необходимости, может быть повторён. Например, открытый системный вызов должен быть дополнен ADF-запросом для получения доступа на чтение к каталогу, созданию каталога/файла, усечения файла и для дополнения-/чтения-/записи/чтения-записи-открытия файла.
Каждое состояние функции перехода в модели секретности вызвано системным вызовом. Поэтому AEF был дополнен системными вызовами (change-current-task, create-personal-data, точно так же, как и все привилегированные системные вызовы для добавления или удаления 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 | системное время |
Модуль ADF приняв запрос о предоставлении доступа от AEF оценивает его при помощи правил различных политик безопасности. Схема 4, например, демонстрирует правила политики секретности ADF для запросов типа append-open. Язык спецификации должен быть интуитивно понятен для широкой аудитории, а так же его описание имеется в [LaPadula 1995]. В этой спецификации следующие предикаты соответствуют следующим значениям:
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);
Для соответствия с моделью секретности файлы личных данных могут быть созданы при помощи системного вызова 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 цели текущей задачи процесса.
Этот проект демонстрирует каким образом законные требования секретности могут быть технически внедрены в систему. Первые тесты реализованной нами системы со сценарием воображаемой больницы продемонстрировали, как может быть расширена секретность. Концепция 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.
Составители:
Amon Ott <ao@rsbac.org>
Simone Fisher-Hubner <simone@dsv.su.se>
Перевод:
Александр Блохин <sass@uustoll.ee>
Следующий раздел описывает концепцию формальной модели секретности, непосредственно назначающей основные законодательные требования секретности, такие как взаимосвязанность целей или необходимость обработки данных. Политика секретности, предписываемая этой моделью, может быть неофициально описана как следующая:
Пользователь получит доступ к личным данным только в том случае, если это связано с выполняемой им/ею задачей и только, если он авторизован для выполнения этой задачи. Пользователь может получить доступ к данным только в установленном порядке, посредством выполнения (сертифицированной) процедуры преобразования, для которой авторизована текущая задача пользователя. Кроме того, цель его/ее текущей задачи должна соответствовать целям, для которых были получены личные данные или владелец данных должен быть поставлен в известность об этом.
Эта формальная, задаче-ориентированная модель секретности позиционируется как модель государственного механизма. Модель секретности содержит следующие переменные состояния, инварианты, ограничения (свойства секретности) и функции перехода состояния (правила модели):
В модели секретности определены следующие защищённые (или лучше: секретные) состояния:
Субъекты 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.
Следующие инварианты определяют условия для системного состояния для объединения специфических принципов секретности (так называемого секрето-ориентированного состояния). Формально, они определяют вышеупомянутую политику секретности. Для предписания такой политики секретности должно быть обеспечено создание этих инвариант в каждом системном состоянии, определенном переменными состояния.
Если пользовательским ролям назначены авторизованные задачи, то в первом инварианте секретности AT(Si) будет заменено на AT(role(Si)).
Пример: Следующий пример демонстрирует различия между концепциями необходимости обработки данных и концепцией взаимосвязанности целей: В больнице, в "лечебных" целях, собраны "данные диагностики". Для исследователя необходимо провести статистический анализ при помощи программы статистики с доступом на чтение к данным диагностики. Таким образом, должны быть назначены соответствующие необходимые права доступа I NA. Задача "статистический анализ" обслуживает цель "исследование". Следовательно, принцип взаимосвязанности целей позволяет получить доступ к даным диагностики пациента в исследовательских целях только с согласия пациента.
При создании или удалении личных данных также должны быть соблюдены принципы необходимости обработки данных и взаимосвязанности целей. Эти принципы могут быть сформулированы добавлением ограничений, являющихся свойствами последовательности состояний (ограничение отличается от инварианта, так как оно принимает во внимание отношения между значениями в двух последовательных состояниях - перед и после каждой функции перехода состояния). В следующем примере символ *, после переменной состояния, используется для обозначения нового состояния.
В модели приватности субъект может получить доступ к объекту в том случае, если цель его/её текущей задачи содержится в наборе целей, для которых получены данные объектного класса. Следующий сценарий атаки (в пределах больницы), приведённый на схеме 1, допускает существование незаконного потока информации.
Субъект выполняя задачу 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.
Функции перехода состояний, которые описывают все возможные изменения переменных состояния, предназначены для действий, связанных с получением допуска, возвратом допуска, созданием объекта, удалением объекта, изменением текущей задачи, выполнением процедуры преобразования , выходом из процедуры преобразования.
Кроме того, привилегированные функции необходимы для определения или изменения информации управления доступом, такой как задачи, цели, авторизованные задачи для субъектов, авторизованные процедуры преобразования для задач, классы объектов и их цели, необходимые допуски и соглашения. Эти привилегированные функции могут быть выполнены только офицером безопасности. Однако, в случае поддержки "принципа 4-х", администрирование информации управления доступом может быть выполнена совместно с другим человеком, который печётся об интересах секретности субъектов данных. Этот другой человек мог бы быть например, офицером защиты данных в организации или рабочем совете (в соответствии с Немецким постановлением о защите данных, каждая организация, занятая обработкой информации о личности, обязана назначить офицера защиты данных. В директиве ЕС о защите данных присутствует аналогичная роль "соответственного за защиту данных"). Сначала, офицер защиты данных, ответственный за внедрение инструкций секретности в организации и за становление политики секретности, определяет всю необходимую информацию управления доступом. Затем, офицер безопасности отвечающий за внедрение политики безопасности, приводит информацию управления доступом в соответствие этим требованиям.
Для определения и реализации таких схем совместного действия, существует другая системная переменная для "одноразовых" маркеров: Ticket TKT(Si, function-type, parameter-list): составлен для Субъекта Si и отправлен офицеру безопасности (пользователю с ролью "sec-officer"). Это означает, что Si запрашивает у офицера безопасности разрешение на выполнение некоторых функций с некоторыми параметрами. Обычно, составителем маркера является пользователь в роли "data-protection-officer" или пользователь, ответственный за задачу, если авторизация для этой задачи может быть предоставлена или аннулирована от другого субъекта. TKT представляет из себя набор всех составленных маркеров. Офицер охраны с соответствующим маркером может выполнять соответствующую привилегированную функцию:
Формально, для всех функций перехода, доказано, что они сохраняют инварианты секретности, ограничивая также, как инвариант информационного потока. Таким образом, при помощи математической индукции можно показать, что если система, предписывающая модель секретности, выполнена в среде ориентированной на секретность, то все последующие состояния системы также будут секрето-ориентированы.
В проекте определено как должна внедряться политика секретности с соответствии с архитектурой 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]) это расширяющая секретность технология проверки безопасности, где данные, идентифицирующие пользователя в записях проверки скрыты под псевдонимами.
В соответствии с с архитектурой GFAC, Защищенная (доверенная) Вычислительная Среда (TCB) состоит из модуля управления доступом (AEF) и модуля принятия решения управления доступом (ADF). ADF реализует принудительную системную политику безопасности и мета-политику для решения, удовлетворяют ли запросы процессов этой политике защиты. AEF использует решения ADF для проведения операций с уместными, в плане безопасности, функциями системного вызова.
В GFAC, система управления доступом ядра системы, разделена на AEF- и ADF-компоненты и модуль ACI для управления Access Control Information (ACI, например, атрибуты безопасности). Схема 3 показывает взаимодействие между компонентами системы. Для каждого уместного, с точки зрения безопасности, системного вызова, например, при обращении процесса к объекту (файлу, каталогу, данным управления защитой (scd) или данным межпроцессного взаимодействия (ipc)), или если процесс желает клонировать себя или послать сигнал, AEF направляет запрос решения к ADF. Параметрами для запроса решения являются тип запроса, описывающий желаемый тип функциональности, идентификация вызывающего процесса и, по возможности, идентификатор цели доступа (субъект или объект). ADF оценивает политику защиты при помощи правил политики для типа запроса и для этих правил необходим ACI. Если затем оценивается его мета-политика, то используются решения различных политик защиты для окончательного определения запроса процесса. Затем AEF реализует решение либо выполнением функций системного вызова, либо возвратив вызывающему процессу сообщение об ошибке. В первом случае, после успешного выполнения, ADF получает уведомление, в следствие чего атрибуты могут быть приведены в соответствие. И наконец, контроль возвращается к процессу.
Технологии приватности в последнее время становятся всё более и более актуальны, так как индивидуальная секретность в Глобальном Информационном Сообществе подвержена опасности. В этом документе описывается обновлённая версия формальной модели приватности, которая может быть использована для технического внедрения законодательных требований секретности. Этот документ демонстрирует, как может быть определена и реализована политика приватности в соответствии с Generalized Framework for Access Control (GFAC).
В нашем сетевом сообществе, злонамеренный код (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-системой против манипуляций и контролем/сканированием выполняемого кода.
Единственное возможное, и часто осуществляемое решение, это размещение дополнительных мониторов управления доступом на прикладном уровне. Это сделано в языке сценариев веб-броузеров 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, для уверенности в безопасности этих аплетов. Однако, сами-по-себе сертификаты ничего не решают. Они повышают доверительный уровень аплета, идентифицируя сверх разумных пределов его происхождение. то не защищает аплет от внесения в него злонамеренного кода составителем сертификата.
Для реализации более безопасного окружения необходимо, чтобы все приложения регистрировали все объекты, которые они определяют в операционной системе и использовали средства операционной системы для предоставления или отказа в доступе к таким образом обозначенным объектам. Это требовало бы отделение интерпретатора от программы запроса и чтобы объектная модель программы предоставлялась операционной системе. Это предотвращает размещение мониторов управления доступом не прикладном уровне и сохраняет централизованную систему безопасности.
Word 7.0 для Windows мог бы быть перепроектирован для соответствия с такой моделью. Сам Word многие из своих объектов не использует, а для выполнения кода содержащегося в документах пользуется набором объектов принадлежащих VBA (доступ к которому получает при помощи другого набора объектов принадлежащих OLE 2.0). К нашему сожалению, после предоставления программе и документу доступа, контроль доступа к любому другому объекту не может быть использован. Однако, в операционной системе где используется контроль доступа для всех программ, во избежание нарушения безопасности и приватности, может быть реализован принудительный контроль доступа.
Тоже-самое может быть сказано в отношении Java. Java осуществляет гораздо более строгие меры защиты, чем VBA, так как она была создана для использования через Интернет, где не известны намерения поставщика услуг. Однако, назначение политики безопасности остаётся за программой, выполняющей Java, обычно это Веб-броузер. Тип политики безопасности, реализуемый броузером, может быть не совместим с политикой безопасности компании, например, он может не поддерживать разрешенный доступ аплетов Java к локальной файловой системе во встроенных приложениях, но позволять Java-аплету загрузку программного обеспечения на локальный диск в несоблюдение политики компании. Централизованный контроль доступа предоставляет более эффективную защиту.
Мы показали, что такая простая модель программы как работа текстового редактора с простым документом, нуждающаяся в предоставлении или отказе системой запрошенного доступа, поддерживается не достаточно хорошо. На рисунке 2 мы видим то, что файл может быть внутренне разбит на множество объектов и даже содержать выполняемый код, интерпретируемый приложением. Другим примером может служить комплексная структура HTML-документа, содержащего аплеты Java или объекты ActiveX.
Вызов защите бросает то, что каждый из объектов этого файла может обладать различными требованиями к защите, но нет никакой возможности использовать защиту этих объектов без помощи со стороны самих программ.
Для примера позвольте использовать отчет, написанный Фредом. Главный документ содержит введение и общую информацию о его компании. Аналитиком в главный документ внедрен еще один, содержащий важную финансовую информацию. Он хочет оставить возможность другим служащим читать основной документ, одновременно ограничив доступ к ценной информации во внедренном .
Проблема, с точки зрения защиты, состоит в том, что управление доступом в файловой системе не распространяется на документы, содержащиеся внутри файла. Атрибуты доступа файла, унаследованные документами, не обязательно совпадают. Для получения хотя бы одного документа, содержащегося внутри файла, пользователю необходим доступ ко всему документу. В частности, приложения часто сохраняют выполняемый код документа в пределах файла, который выполняется практически вне прямого управления операционной системы.
Аналогичная проблема существует со многими документами HTML. Документ содержит много ссылок к другим документам, таким как изображения и выполняемый код. Обычно, такой код выполняется в пределах виртуальной машины, например, Java, или настоящей, например ActiveX.
Активному содержимому HTML-страниц уделено больше внимания, чем было уделено активному содержимому в обычных документах. Sun проделала большую работу для защиты пользователя от злонамеренных Java аплетов, согласившись в конечном счете, что эту проблему решить невозможно. Microsoft по крайней мере обозначил проблему, хотя и не достаточно, предоставив метод аутентификации объектов ActiveX при помощи сертификатов. Эта схема сертификации распространяется на файлы Word и Excel из состава MS-Office (версии "2000"). Первоначально предполагалось, что большого обмена такими файлами не будет, и выполняемый код оставался бы заключенным на пользовательской машине. Однако, все больше и больше документов Word пересылается по электронной почте и публикуется Интернете, представляя из себя большую угрозу пользовательской безопасности и приватности.
Дальнейшие проблемы возникают, когда мы пробуем придать защите строгую политику. Определенные объекты часто различны по своей природе и в такой ситуации не существует простого способа коррелировать объектный доступ. Например, в VBA программа имеет доступ к встроенному редактору/компилятору и, следовательно, к исходным текстам программы. Хотя любая обычная программа в целом и имеет доступ к файлу, это не предоставляет простого доступа к коду, поскольку это требует сложного синтаксического анализатора формата файла, требующего неопубликованную документацию. Это требовало бы управления доступом к программному коду во избежание активизации VBA-вирусов при обычных операциях с документами.
Тема будущего исследования должна определить модель взаимодействия приложений для операционной системы, которая позволит использовать строгую политику без лишения пользователей функциональных возможностей.
В этом документе мы продемонстрировали как мы реализовали в 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.
[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.
Составители:
Simone Fischer-Hubner, Stockholm University, Department of Computer and Systems Sciences (DSV), (on leave from Hamburg University), <simone@dsv.su.se>
Morton Swimmer, IBM T.J. Watson Research Center / Yorktown, Heights, New York, USA, <swimmer@us.ibm.com>
Перевод:
В проекте Гамбургского Университета, официальной является политика безопасности 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 получает уведомление, в следствие чего атрибуты могут быть приведены в соответствие. И наконец, контроль возвращается к процессу.
При помощи GFAC-концепции, интегрировав компоненты правил политики сканера в ADF и добавив информацию контроля доступа в модуль администрирования ACI, мы реализовали On-Access-сканер. Хотя GFAC и был первоначально разработан как средство для выражения и интеграции компонент политики формальных моделей защиты (обычно, статическиемодели машинного типа), мы продемонстрируем, что это также может быть использовано для интеграции эвристической политики. В вирусных сканерах всегда присутствует элемент эвристики, так как не существует методов для уверенного определения наличия вируса в файле. Антивирусными средствами в настоящий момент гарантированно могут быть обнаружены только уже известные вирусы. Дополнительные ACI-правила и политики, необходимые для интеграции и реализации компонентов политики сканера, описаны в следующих параграфах.
Информация Контроля Доступа :
Для каждого файла используется новый атрибут защиты MS-scan-result. Допустимыми значениями атрибутов scan-result являются: номер версии, "rejected" (отвергнуто) или "unscanned" (не сканировано). Атрибут файла scan-result имеет значение номера версии сканера, если файл был сканирован с этой версией сканера и не была найдено инфекции. Если файл был сканирован и была обнаружена инфекция, то атрибут файла будет установлен в значение "rejected". Атрибут файла "unscanned" используется в том случае, если файл не был сканирован или претерпел изменения с момента последней проверки.
Также у программ имеется атрибут MS-trusted. Этот атрибут устанавливается для антивирусных и программ резервного копирования, а также для процессов, выполняющих эти программы. Кроме того, ACI-модуль управляет базой данных вирусных образцов/сигнатур, к которым также прикреплён номер версии.
Правила политики сканера вызываются при каждом направленном к ADF или AEF запросе на открытие или выполнение. Заражение файловым вирусом происходит при выполнении зараженного файла, тогда как заражение макровирусами происходит при чтении зараженного документа. Таким образом, каждый запрос от AEF к ADF на чтение или выполнение файла, если файл сначала был проверен последней версией сканера и не было обнаружено заражения, должен иметь только положительную оценку от ADF.
Следовательно, если запросами являются execute, read-open или read-write-open, то правилами принятия решения будут следующие :
Интеграция правил сканирования со средством принятия решения о доступе (ADF), не оказывает существенного влияния на работу системы в целом. Для прочтения файла, при запросе на чтение (или чтение-запись), вызываются правила сканирования и, будучи единожды вызваны, остаются резидентно для последующих операций чтения. Кроме того, при открытии на execute-, read-open и read-write-запросах, файлы проверяются только на предмет изменения или соответствия версии сканера, установленного в системе (то есть, если вирусная база данных образца была дополнена и получила новый номер версии). Проблематичными являются комплексные файлы, содержащие и данные и код, которые могут быть проверены чаще, чем это необходимо. К этой проблеме мы вернёмся позднее.
On-Access-сканер злонамеренного кода, описанный в последней секции, обеспечивает надежную и устойчивую к фальсификации защиту против известного злонамеренного кода, содержащегося в исполняемых файлах. Однако, все чаще и чаще злонамеренный код попадает в систему через сетевые подключения, не храня себя при этом в файле.
В настоящее время становятся популярными методы, используемые для просмотра трафика в системах сетевой защиты, которые, технически, в состоянии защитить локальную сеть от злонамеренного кода, просматривая всю передачу в различных прокси-серверах для различных протоколов высокого уровня. При таком способе защита всех локальных компьютеров рассчитана на знание и управление всеми подключениями в локальной сети. Каждое дополнительное подключение должно быть защищено при помощи дополнительных механизмов и каждый прокси-сервер должен иметь надежный сканирующий механизм, увеличивающий рабочую нагрузку на системе сетевой защиты.
Недавно мы начали работу над другой методикой, где каждая машина в состоянии себя защитить при помощи всего лишь одного экземпляра сканера злонамеренного кода в ядре системы.
Дополнительные правила сканирования, также являющиеся частью ADF-компонента GFAC-системы, управляют всеми доступами на чтение на сетевых подключениях. Если в потоке данных обнаруживается некий известный злонамеренный код, то дальнейший доступ для чтения отклоняется и возвращается новый код ошибки "malware-detected". Соединение, в зависимости от конфигурации, может быть либо блокировано ядром, либо доверенный процесс может запросить о непрерывной передаче, которая будет ему предоставлена.
Индивидуальная защита каждого компьютера может способствовать уменьшению воздействия злонамеренного кода, проникшего в локальную сеть, миновав систему сетевой защиты. Это может быть вторым уровнем проверки, после системы сетевой защиты. Однако, здесь все-еще присутствует основная проблема с кодированием на программном уровне, свойственная всем системам сетевой защиты, так как пока обнаружению поддаётся только злонамеренный код, набранный открытым текстом.
Все сетевые соединения в системе 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, который может иметь три значения:
В дальнейшем может быть добавлена такая возможность как таблица отправителей, чтобы блокировать только злонамеренных отправителей, но данный механизм все-таки допускает возможность подмены адресов.
Воздействие сканирования на уровне сокетов на сетевую производительность всё-ещё не измерено, но оно определяется, главным образом, алгоритмом сканирования и и количеством выполненных циклов. Основной запрос решения на стандартном Pentium PC, работающем с 10 Mbit Ethernet, как показывают наши тесты для других компонентов RSBAC, не заметен.
Главное ограничение в способе сканирования злонамеренного кода на уровне сокетов заключается в том, что он не в состоянии определить злонамеренный код на уровне выполняемого кода программ. Таким образом, другой способ состоит во включении в управление доступом большей информационной базы известных прикладных программ, и мы обсудим несколько таких способов в следующем разделе.
Принимая во внимание то, что предыдущий способ предупреждения вирусов хорош для кода, выполняемого непосредственно в операционной системе, программный код тоже не подходит под эту модель. В то-же время использование определенных правил 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" зашифрован, то сканер не сможет его проверить. Однако программа в состоянии его дешифровать, тем самым решив эту и другие проблемы защиты, существующие на программном уровне.
Описывается реализация политики принудительной вирусной защиты. Эта политика реализуется в рамках 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.
Описывается реализация политики принудительной вирусной защиты. Эта политика реализуется в рамках 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.
Ключевые слова: Security model, Role-based access control, Generalized Framework for Access Control (GFAC), Web security, Secure Internet server administration
Одна из главных областей серверного применения системы Linux является область Web-серверов. Имеются следующие риски в функционировании системы:
Если используются различные типы сценариев CGI, то должны быть назначены дополнительные CGI-роли. При использовании форсированных ролей, сценарии CGI, которые не могут запускать другие программы, могут быть выполнены с правами root без риска для безопасности.
В окончательной версии документа мы приведём больше примеров. демонстрирующих как наша модель способна реализовать защиту интернет-сервера.
Методика 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].
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,
.
Составители:
Amon Ott, Compuniverse, Hamburg/Germany, <ott@compuniverse.de>
Simone Fischer-Hu"bner, Karlstad University, Karlstad/Sweden, <Simone.Fischer-Huebner@kau.se>
Перевод:
Недавно, появилось и получило признание как метод управления защитой, ролевое управление доступом.
Мы создали 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-сервера.
Концепция защиты Role-Compatibility Model может быть охарактеризована следующим образом:
Субъект может достигнуть объекта выступая в роли, которой гарантирован доступ. Кроме того субъект, пребывающий в некоторой роли, может получить доступ к объекту только в том случае, если его текущая роль имеет доступ данного вида к объектам данного типа (мы говорим, что роль должна быть "совместима" с типом объекта и режимом доступа).
Пользователи и процессы:
В RC-модели пользователь - человек, субъект представляет собой активный пользовательский процесс. В следующем определении модели мы будем использовать процесс вместо объекта.
Владельцем каждого процесса является пользователь:
В RC-модели защищенными объектами являются любые из класса "f/d" (файлы или каталоги), "ipc" (объекты межпроцессного взаимодействия, такие как разделяемая память, запросы или сокеты), "dev" (файлы устройств), "scd" (данные контроля системы системные данные такие как порты ввода/вывода, часы и т.д. ) и "процессы" (объекты также могут быть субъектами).
Объекты могут быть разбиты на категории в соответствии с их типами:
Каждая роль задается набором прав доступа, которые определяют возможности по выполнению операций над конкретными типами объектов и другими ролями.
Для каждого класса объектов определены различные режимы доступа. Если быть более точным, то это:
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).
Каждый процесс, в отдельно взятый момент времени, выполняет одну роль.
Правило 1: Первый процесс p1 (init) получает заданную по умолчанию роль системного пользователя root:
Правило 2: После создания процесса, текущей ролью pnew является роль его родительского процесса p:
then rc-role*(pnew) = rc-role (p)
then rc-role*(p) = rc-default-roledef-role(owner*(p))
Важным принципом защиты для сохранения целостности является запрещение произвольного доступа субъектов к данным объекта, и последующее разрешение доступа к данным только определённым способом, выполнением четко определённых программ. Наша модель допускает принудительное соблюдение этого принципа через концепцию "форсированных ролей". Каждый исполняемый файл имеет атрибут rc_forced_role, который имеет либо значение NIL (не форсированная роль), либо определяет так называемуюфорсированную роль? которую получит процесс при запуске данного файла. Все это очень похоже на стандартный механизм Unix SUID.
Концепция форсированной роли может быть использована для ограничения привилегий суперпользователя в Unix системах, например для ограничения доступа к авторизационной информации (/etc/passwd, /etc/shadow) для некоторых программ с форсированной ролью "Autorisation". Пример:...
Каждый процесс имеет атрибут защиты "rc-forced-role", который сохраняет значение rc-forced-role программы выполняемой в случае смены владельца.
Процесс проходит авторизацию для своей первоначальной роли (которая является заданной по умолчанию ролью его владельца создавшего родительский процесс или ролью root в случае первого процесса (init)) и для всех последующих ролей которые он может иметь.
Процесс может менять роли только на подходящие (через специальный системный вызов), на роли, заданные по умолчанию, его новых владельцев путём изменения владельца (через setuid) или форсированием роли программы при её выполнении.
Формально это правило может быть выражено следующим образом:
Правило 3.4: `` p:process,rolem,rolen:role:
с rolen = rolem или rolen rolem совместима с rolem rolen
или rolen = rc-def-role(владелец*(p))
или rolen = rc-forced-role*(p).
Правило 5: `` p:process, o:object:
С версии 1.1.2 RSBAC предоставляет постоянные общие списки с настраиваемым индексом и размером данных и автоматическим созданием резервных proc-файлов. Полное описание будет в ближайшее время. А пока, пожалуйста, смотрите заголовочный файл include/rsbac/lists.h.
Все эти функции требуют предопределенного пространства для строки имени. Для удобства возвращается тот же самый указатель действия. Декларации
Эти, и некоторые name-to-value-функции, могут быть также использованы в пользовательском инструментарии, просто скопируйте getname.c, скомпилируйте его в getname.o и соедините с вашей программой. Загляните в инструментарий администратора RSBAC, что бы видеть как это используется.
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. */
extern int rsbac_printk(const char *, ...);
/* log to rsbac log - use like printk(9) */
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 */
Пожалуйста, не меняйте значения и не удаляйте пункты, если вы не уверены в том, что вы знаете что делаете, так как на них завязаны другие модели.
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 */
Обратите пожалуйста внимание, что файловый доступ в каталогах /rsbac к файлам и каталогам не должен выполняться со стандартными системными вызовами - они будут перехватываться и, по возможности, блокироваться. Предохраняйте rsbac_write_sem от открытия раньше, чем файл будет закрыт.
Предупреждение: чтение и запись из и в область ядра требует изменение дескриптора сегмента - смотрите reg_sample2.c как пример того, как это все делается.
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 *);
Для регистрации в этих каталогах используйте пожалуйста стандартные функции ядра Linux create_proc_entry() и remove_proc_entry().
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 */
Составитель:
Перевод:
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, из-за добавленных функциональных возможностей и (я надеюсь) более легкого использования.
Вся процедура регистрации модуля решения осуществляется с использованием идентификаторов rsbac_reg_handle_t, которые являются 32-битным числом. Как правило положительные значения используются как реальные значения и отрицательные для ошибок.
Типы данных и определения функций REG могут быть найдены в include/rsbac/reg.h, все остальное находятся в include/rsbac/types.h. Эти файлы заголовков должны быть всегда включены в вашу реализацию модели.
Полный список запросов RSBAC с возможными целями находится в документе, описывающем Цели и Запросы .
Вы можете регистрировать следующие функции:
( 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 */
( 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 */
(struct dentry * dentry_p);
Для регистрации модуля вы сначала выбираете положительное, 32-х Битное целое со знаком число, это будет ваш персональный дескриптор. Он будет требоваться при всех дальнейших процедурах связанных с регистрацией. Если случится так, что выбранный вами дескриптор в данный момент используется, то вам будет отказано в регистрации со значением ошибки - RSBAC_EEXIST.
rsbac_reg_syscall_entry в struct содержит все необходимые значения. Функция может быть не учтена установкой ее указателя в значение NULL. Ваш модуль позднее будет идентифицирован в сообщениях REG и proc-файлах по его имени. Текущая максимальная длина имени 30 знаков.
Значение переключателя определяет, будет ваш модуль с самого начала включен или выключен. В целях безопасности переключение работает только в том случае, если оно задействовано в конфигурации ядра.
{
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 это значение версии REG, которое позволит производить проверку версий для модулей поставляемых в бинарном виде. Оно должно быть всегда установлено в значение RSBAC_REG_VERSION. Функция регистрации возвратит ва положительный дескриптор или отрицательный код ошибки (для дополнительной информации смотри include/rsbac/reg.h).
( rsbac_version_t version,
struct rsbac_reg_entry_t entry);
(rsbac_reg_handle_t handle, boolean value);
(rsbac_reg_handle_t handle);
Позвольте мне намекнуть на примеры модулей - использование их, для начала, будет хорошим выбором и предохранит вас от излишнего печатания.
Регистрация системных вызовов подобна таковой в модуле принятия решения. Как и с функциями принятия решений, здесь не существует официального ограничения на количество регистрируемых syscall. Только дескрипторы должны каждый раз отличаться.
В целях безопасности, для регистрации и организации syscall должны использоваться разные значения дескрипторов - дескрипторы syscall-диспетчера должны быть доступны для любого использования.
Ваш системный вызов, будучи однажды зарегистрированным, может быть вызван официальным системным вызовом:
(rsbac_reg_handle_t handle,
void * arg);
Ваша -syscall-функция должна выглядеть следующим образом:
int rsbac_get_user
(unsigned char * kern_p, unsigned char * user_p, int size);
Теперь, для регистрации syscall, вы выбираете положительное, 32-х Битное целое со знаком число, как ваш персональный дескриптор и другое, подписанное 32-х Битное со знаком значение, как ваш публичный дескриптор syscall-диспетчера. Все действия, связанные с регистрацией, позднее будут нуждаться в этом уникальном секретном дескрипторе. Если случится так, что ваш дескриптор в данный момент используется, то вам будет отказано в регистрации со значением ошибки - RSBAC_EEXIST.
struct rsbac_reg_syscall_entry хранит в себе все необходимые значения. Может быть не учтено только имя. Ваш системный вызов позже будет идентифицирован в сообщениях REG и proc-файлах по их имени и дескриптору публичного диспетчера. Текущая максимальная длина имени ограничена 30 знаками.
{
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 является значением версии REG, что позволит производить проверку версии для модулей полученных в бинарном виде. Оно всегда должно быть установлено в RSBAC_REG_VERSION. Функция регистрации возвратит ваш положительный дескриптор или отрицательный код ошибки (для дополнительной информации смотри include/rsbac/reg.h)
( rsbac_version_t version,
struct rsbac_reg_syscall_entry_t entry);
(rsbac_reg_handle_t registration_handle);
Структура RSBAC предоставляет много вспомогательных функций и переменных, которые могут быть использованы вашим модулем в случае их пригодности.
Для различных задач необходимо распределить области памяти. Особенно в ядре Linux, где пространство стека довольно сильно заполнено, так что часто Вы просто не сможете объявить большую переменную и надеяться, что она сработает.
Обычный способ распределения памяти заключается в использовании kmalloc/kfree при довольно малых количествах (размещенных неразрывно как реальная память) и vmalloc/vfree (виртуальной памяти) при больших размерах. К сожалению, вы сами должны определить какой способ для вас предпочтительнее. kmalloc вызовет ошибку при попытке размещения более чем 128М - так или иначе, доступ к непрерывной памяти на нескольких страницах может быть затруднителен.
Начиная с версии 1.1.2 RSBAC предоставляет собственные функции управления памятью. Также, при включенной поддержке REG, эти функции экспортируются для модулей.
В версиях ядра с 2.4.0 отдельные участки памяти используются как память kmalloc-стиля для предоставления лучшего контроля над использованием памяти через /proc/slabinfo.
(size_t size, boolean * vmalloc_used_p);
Составитель:
Перевод:
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-модель администрирования |
Перед тем, как будет разрешен доступ к объекту, производится запрос к средствам 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>>.
Составитель:
Перевод: