[ новости /+++ | форум | теги | ]

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

Начала RSBAC.

Прежде чем мы начнем с вами превращать свой компьтер в неприступную крепость необходимо сначала разобраться с тем, что вас ожидает. Любая система безопасности вносит ограничения в вашу деятельность, а серьезная система вносит очень серьезные ограничения. Дополнительные проверки и авторизации понижают производительность ядра, а такие вещи как безопасное удаление понижают скорость работы файловой системы. Забудьте про всесильного суперпользователя, его всесилие одна из наиболее серьезных проблем безопасности. Теперь у вас будут отдельно администратор системы (в дальнейшем просто администратор) и администратор безопасности( в дальнейшем офицер безопасности). Оба не смогут влиять друг на друга и даже будут конкурировать за власть в системе. Администратор сможет по-прежнему управлять системой в целом, производить настройки, заводить и удалять пользователей, ограничивать использование пользователями системных ресурсов(см. статью "Начала PAM"). Офицер безопасности будет  ограничивать всех пользователей (включая администратора) в доступе к тем или иным данным, в том числе и системным. Например, администратор, в отличие от офицера, сможет заводить пользователей, но не сможет вручную редактировать файлы /etc/passwd и /etc/shadow, если не разрешит офицер. Будьте осторожны при внесении очередных изменений, вы можете перестараться и перекрыть доступ в систему ВСЕМ, single user не поможет (против ядра нет приема), единственное спасение загрузка с обычным ядром. Последнее тоже непоможет если вы еще добавите шифрованную файловую систему с привязкой к ядру.

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

Создание ядра.

Что надо для работы:

Возьмите последнюю версию системы RSBAC. Вам потребуется два архива: rsbac-текущая-версия.tar.gz и rsbac-admin-текущая-версия.tar.gz . Первый содержит необходимые добавки к ядру, второй утилиты для администрирования.

Заведем в системе нового пользователя secoff и, отредактировав вручную файл /etc/passwd, присвоим ему uid равным 400. Потом при первой загрузке системы он автоматически станет офицером безопасности.

Положим ядро подходящей версии в стандартный каталог /usr/src/linux, подходящяя версия или нет определяется из наличия/отсутствия файла заплатки. Откройте где-нибудь архив rsbac-текущая-версия.tar.gz и в каталоге ./rsbac поищите файл вида patch-ваша.версия.ядра.gz. Замечание: начиная с версии 1.0.9b все патчи лежат отдельно в patch dir на www.rsbac.org. Итак, если таковой найдется, то продолжаем, иначе поговорите с автором или скачайте из Internet'a другое ядро.

Копируем архив rsbac-текущая-версия.tar.gz в каталог /usr/src/linux и разворачиваем программой tar. Далее заходим в каталог /usr/src/linux/rsbac, копируем оттуда в /usr/src/linux подходящую заплатку, разжимаем ее програмой gunzip и накладываем командой patch -p1<patch-версия. Вот и все, самый сложный, механический этап пройден, дальше начинается творчество. Стандартной командой make menuconfig запускаем меню настроек ядра и с удивлением обнаруживаем в нем новый пункт "Rule Set Based Access Control (RSBAC)". Вот мы и встретились с темой нашего повествования. Эта мощнейшая система и позволит нам превратить обычный бытовой Linux в защищенный компьютер класса где-то около B1. Слово около означает, что если мы еще немного приложим собственных усилий, в том числе и программистких, то вожделенный уровень будет достигнут.

Настроив остальные компоненты ядра, дрожащими руками подводим выделение к пункту RSBAC и вспотев от волнения нажимаем Enter.
Помимо пунктов выставленных по умолчанию проверьте следующие:

• RSBAC proc support-в каталоге /proc появляется подкаталог rsbac-info, требуется для программ администрирования, после введения окончательных настроек лучше отключать дабы меньше привлекать к себе внимание. Если не будут знать какая у вас установлена система безопасности, то потребуется больше усилий для взлома.
• RSBAC maintenance kernel-соберите два ядра, одно с влюченным параметром (отладочное ядро), другое без оного(стандартное ядро). Первое дает вам последний шанс ощутить себя root'ом и может потребоваться когда вы случайно потеряете всякий контроль над системой. Второе ядро и будет нашим основным рабочим.
• support secure_delete-Файлы будут удаляться безвозвратно, но, соответственно, замедляется работа файловой системы.
• RSBAC individual logging-дополнительное протоколирование доступа к файлам, каким вы пожелаете. Подробнее об этом будет рассказано дальше по тексту.
• Log full path-Если вы не включите этот пункт то в журнале будет прописано только имя файла, доступ к которому протоколируется, иначе полный путь к нему.
• RSBAC extra stsistics-Появится статистическая информация в /proc/rsbac-info/xstats и в записях журнала будут более исчерпывающие данные.

• Модуль auth - общее слежение за процессами, не позволяет им менять свой uid как попало.
• Модуль RC(Role Compatibility)- Очень серьезная модель доступа основанная на ролевой модели. Решает большинство проблем разраничения доступа с минимальными затратами.
• Модуль MAC(Mandatory Access Control)-мандатная модель доступа на основе известной модели Белла-Ла Падула, только по сравнению с ней несколько модифицированная .
• Модуль ACL (Access Control Lists)-Расширяет права файлов по сравнению со стандартными, позволяет контролировать такие вещи как добавление файла в ядро, запуск файла, смена каталога и иные с точностью до индидуального пользователя, группы пользователей или роли из модели RC

После того как все настройки окончательно произведены, сохраняем их и собираем ядро. Еще раз обращаю внимание на то, что лучше собрать и отладочное ядро и обычное. Сначала соберите обычное ядро, потом выделите пункт "RSBAC maintenance kernel" и, ничего больше не трогая, соберите отладочное.

На этом подготовительный этап еще не закончен. Распакуйте в каком-либо каталоге архив с утилитами администрирования, соберите их и проинсталлируйте. При сборке скорее потребуется подправить параметр KERNELDIR в Makefile. Помимо всего прочего, у вас будет создан  каталог /rsbac - это зачаток будущей базы данных о доступе к файлам. Если вы перестараетесь с настройками, загрузитесь обычным ядром и удалите оттуда все файлы кроме useraci. Это позволит начать все с начала. Замечание: подобная база создается на каждой примонтированной файловой системы, поэтому, возможно придется удалить  еще насколько каталогов.

Важный момент : в версии 1.0.9b административные утилиты не создают каталог rsbac. Вместо них это делает ядро, если такового не существует. Оно же создает useraci файл (на самом деле создает только параметры по-умолчанию, но не сам файл). Поэтому вам надо удалить всё целиком. Если вы этого не сделаете, то останутся пользователи с неопределенными ролями. Собственно это изменение и было создано для того, чтобы не возникало подобных ситуаций.

Ну вот, ядро есть, утилиты есть, можно работать. При первой же загрузке на вас обрушится море несправедливой ругани , скорее всего не все сервисы запустятся и в систему не будут пускать никого кроме root'a. Не пугайтесь, все в порядке, просто мы резко ужесточили права программ и не сказали им об этом. После внесения некоторых изменений все опять придет в норму. Для начала разберемся  с login'ом. Ведь теперь root ничто и изменения в системе безопасности сможет произвести только офицер безопасности - secoff. Проблема в том, что login меняет свой uid на uid пользователя, который входит в систему, а как было сказано ранее модуль auth за этим очень строго следит. Чтобы разрешить это, запустим ядро с параметром rsbac_auth_enable_login (Второй вариант загрузиться с отладочным ядром, зайти как root и включить для /bin/login параметр auth_may_setuid, пользуясь программой rsbac_menu. Для этого однако сначала прочитайте всю документацию до конца чтобы не наломать дров). Теперь в систему могут заходить все. Больше ядро с этим параметром запускать не потребуется, все необходимые изменения уже внесены. Заходим в систему как secoff и для начала углубляемся в теорию включенных нами моделей безопасности.
 

Модуль AUTH.

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

• auth_may_setuid- процесс с установленным подобным флагом отрабатывает смену прав как ни в чем ни бывало.
• auth_capabilities- здесь мы можем задать список тех uid на которые может переходить данный процесс. То есть если в списке значатся 23, 27 и 45 то процесс может поменять свой uid на 23,27,45 ,но не в коем случае на 66.

Сразу исправим права у служб которые не пожелали работать. Для начала заглянем в системные журналы (secoff простой пользователь и сделать это не сможет, надо зайти для этого как root) и найдем объяснение в отказе на работу. Если обнаружена запись следующего вида, то сразу же все и исправим, если нет то проблема связана с протестом другого модуля и будет решена позже:

Feb 25 12:58:13 stas kernel: rsbac_adf_request(): request CHANGE_OWNER, caller_pid 77, caller_prog_name portmap, caller_uid 0, target-type PROCESS, tid 77, attr owner, value 1, result NOT_GRANTED by AUTH

Это неприятное сообщение означает, что процесс по имени portmap с текущим uid 0 попытался изменить его (CHANGE_OWNER) на 1 (value 1) и модуль AUTH ему не позволил. Что ж, скажем программе portmap, что ей можно это сделать, то есть внесем uid 1 в список допустимых (auth_capabilities).
 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Интересный момент: (Как RSBAC занимается протоколированием сообщений защиты)

Основная схема вывода сообщений RSBAC из ядра в файл журнала следующая:

---------------------------------------------
Kernel
----------    ----------------
|        |    |              |
| printk |    | rsbac_printk |
| kernel |    | kernel       |
| buffer |    | buffer       |
----------    ----------------
----|-----------------|----------------------
  /proc/kmsg         /proc/rsbac-info/rmsg
    |                 |
    |                 |
   klogd             rklogd (или другая программа)
    |                 |
    |                 |
    |                 /home/secoff/rsbac-messages
  syslogd
    |
    |
/var/log/messages

RSBAC может использовать и стендартный путь через syslog, а может манипулировать и с собственным каналом через /proc/rsbac-info/rmsg (или системный вызов rsbac_syslog() ). В последнем случае доступ к чтению буфера ядра получает только администратор безопасности. Поэтому если вы не желаете забивать  /var/log лишними сообщениями или необходимо защитить сообщения RSBAC от чьих-либо посягательств, то следует выбрать соответствующий пункт ("don't log to syslog") во время конфигурирования ядра.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
 
 

Приступаем к ликвидации ошибки. Заходим в систему как офицер безопасности перходим в каталог где расположилась программа portmap (например /sbin) и запускаем главную программу администрирования rsbac_menu. В появившемся меню выбираем пункт "File/Dir Attributes" и попадаем в раздел администрирования аттрибутов файла. Вас сразу поразит, но надеюсь не испугает, какое количество аттрибутов может быть навешено на один несчастный файл. Это разнообразие порождено разнообразием возможных модулей защиты, но работают в текущий момент только те параметры, которые соответствуют запущенным модулям. В нашем случае это AUTH, MAC , RC  и ACL.
Но не будем медлить, все узнаем в свое время. Выберем файл portmap из текущего каталога ("File/Dir List:Choose from listing of last dir"), перейдем в меню добавления допустимых uid и добавим 1. Вот и все, действуя аналогично можно исправить и другие ошибки. Как показывает практика после этого все службы начинают стартовать нормально. Что ж, в системе можно опять спокойно работать, но для настоящего разграничения доступа необходимо познакомиться с более серьезными моделями.
 

Модуль MAC.

Рассмотренная выше модель, несмотря на всю свою значимость очень простая. Все остальные по сравнению с ней выглядят просто как слон рядом с мухой. Модуль MAC реализует модель мандатного доступа, предложенную в свое время Беллом и Ла Падулом,  поэтому сначала немного сухой теории.

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

Каждому объекту и каждому субъекту назначается мандатная метка - уровень доступа, число L и множество категорий M. Последнее представим в виде множества из 64 элементов, где каждый элемент 0 или 1. Будем считать, что множество категорий  M1 является подмножеством множества категорий M2, если для всякой i-ой единицы во множестве M1 существует i-я единица во множестве M2. В противном случае будем говорить, что множества М1 и М2 не пересекаются. Рассмотрим множество мандатных меток, то есть пар {L i , Mi} и введем на нем отношение порядка. А именно, будем считать, что метка { L i, M i} доминирует над меткой {L j , M j} и обозначать это соответственно { L i, M i} > {L j , M j}, если L i >L j и M i надмножество M j .

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

Необходимо иметь еще так называемую матрицу доступа D, где на пересечении i строки и j-го столбца указано какие права доступа имеет i-й субъект к j-му объекту. Могут быть,например, права на чтение, запуск, изменение и запуск. Данная матрица носит название Дискретиционной Модели доступа и в RSBAC она порождается из обычных  прав файлов Unix, с учетом имени пользователя и его группы.

Итак, в модель вносятся следующие правила:

• (ss-property) Если субъект имеет право на запись или чтение к объекту, то принимается, что мандатная метка субъекта доминирует над мандатной меткой объекта.(ds-property)
• (ds-property) Права на доступ объекта к субъекту берутся из матрицы доступа D и только оттуда. Это правило жестко закрепляет связь матрицы доступа со всей моделью.
• (*-proprerty) Если возникает ситуация когда субъект открывает один объект для записи, а второй для чтения, причем метка второго объекта доминирует над меткой первого, то субъект получает отказ в доступе. Данное правило позволяет исключить истуацию перетекания информации от защищенного объекта к незащищенному.
• Решение о доступе положительно, если мандатная метка субъекта доминирует над  мандатной меткой объекта и положительно решение по (*-property).

Создадим какой нибудь файл ~/mactest. Снова запустим из каталога, где лежит данный файл центральную программу администрирования rsbac_menu. Не поленюсь напомнить, что делать все настройки можно только находясь в системе как пользователь secoff - офицер безопасности.
Привычно перейдем в меню администрирования файлов и выберим для настроек файл mac-test. Модулю MAC принадлежат следующие параметры:

• MAC security level -Уровень секретности файла. Установим его, например, в 2.
• MAC categories -Множество категорий файла. Не будем ничего изменять.
• MAC trusted for user -А здесь можно указать доверять ли другим пользователям и если да то кому. То есть доверенный пользователь может формально не иметь доступа, но при выставленном доверии файла к нему его все равно допустят. Здесь мы тоже ничего изменять не будем.

В программе rsbac_menu переходим в меню управления пользователями ("User Attributes: Go to user attribute menu") и с не меньшим удивлением обнаруживаем, что у пользователя дополнительных параметров совсем не меньше чем у файла. Сейчас нас интересуют:

• Security Level- Уровень секретности пользователя. Пользоввтель может прочитать документы с уровнем не больше его собственного.
• MAC Categories- Множество категорий пользователя.

Важный момент: Модуль MAC позволяет производить смену процессу UID пользователя только если уровень секретности текущего пользователя не ниже уровня секретности нового. Это основная проблема того, что администратор (root) всегда имеет максимальный уровень секретности.

Упражнение для разработчиков:
Решите проблему с завышенным уровнем секретности у root'a. Один из возможных подходов состоит в том, что можно добавить новый аттрибут "Enforced MAC security level" , аналогично  аттрибуту "RC enforced role".
 
 

Модуль ACL.

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

Для этого мы включили модуль ACL, который добавляет к обычным правам листы контроля доступа. Ну вижу вам уже не терпится посмотреть их. Создаем каталог ~/acltest, запускаем программу rsbac_menu и выбираем в меню управления правами этого файла (как добраться до него надеюсь вы уже запомнили, если нет- смотрите предыдущий пункт) и выбираем " ACL Menu: Go to ACL menu". Там в отличие от предыдущих случаев никакого обилия прав мы не увидим, но нажмите на пункт "Change  Mask" и ... вам хватит этого?

•  ADD_TO_KERNEL -Добавлять модуль в ядро (для драйвера)
•  ALTER - Изменить контрольную информацию для IPC
•  APPEND_OPEN -Открытие для добавления
•  CHANGE_GROUP-Сменить группу
•  CHANGE_OWNER -Сменить Владельца
•  CHDIR-Сменить Каталог
•  CLONE-Клонировать процесс
•  CLOSE-Запрос на закрытие
•  CREATE-Запрос на создание
•  DELETE-Запрос на удаление
•  EXECUTE-Запрос на запуск
•  GET_PERMISSIONS_DATA-Прочитать права UNIX.
•  GET_STATUS_DATA- Получить информацию о файле ( вызов stat() ).
•  LINK_HARD-Сделать жесткую ссылку
•  MODIFY_ACCESS_DATA -Модифицировать информацию о времене доступа к файлу
•  MODIFY_ATTRIBUTE-Изменить аттрибут rsbac
•  MODIFY_PERMISSIONS_DATA- Изменить права Unix.
•  MODIFY_SYSTEM_DATA- Изменить системные данные.
•  MOUNT-Совершить операцию монтирования
•  READ-Произвести чтение.
•  READ_ATTRIBUTE- Произвести чтение аттрибута RSBAC.
•  READ_OPEN- Открыть файл для чтения.
•  READ_WRITE_OPEN- Открыть файл для чтения-записи.
•  REMOVE_FROM_KERNEL- Удалить модуль из ядра (для драйверов)
•  RENAME-Переименовать
•  SEARCH-Произволить поиск.
•  SEND_SIGNAL-Посылать сигнал дркгим процессам.
•  SHUTDOWN-Выключать/Перезагружать систему.
•  SWITCH_LOG-изменять параметры протоколирования RSBAC.
•  SWITCH_MODULE-Включать/Выключать модули.
•  TERMINATE- Останавливать процесс.
•  TRACE- Трессировать процесс.
•  TRUNCATE-Усекать файл
•  UMOUNT-Выполнять демонтирование.
•  WRITE-Производить запись
•  WRITE_OPEN-Открывать файл для записи.

Выключим для каталога ~/acltest аттрибут CHDIR. И теперь никто не сможет перейти в этот каталог, кем бы он ни был. Давайте сделаем интересней: скажем, пользователю test разрешим все-таки входить в этот каталог. Для этого вернемся в основное меню ACL аттрибутов для файла и выберим пункт "Add ACL Entry:Add group, role or user entry". Нас спросят что же мы хотим добавить. Отвечаем, что пользователя и выбираем оного из списка.Теперь в меню ACL аттрибутов между двумя горизонтальными чертами появилас запись вида USER_его-uid . Выберем ее. Что это? Перед нами снова знакомый список прав. Включим все аттрибуты (в том числе и CHDIR, отключенный в основной маске) и убедимся, что пользователь test и только он может зайти в этот каталог.

Аналогично можно добавить группу пользователей. Так называемую ACL группу. Создать свою группу или отредактировать уже имеющиеся можно зайдя из меню ACL аттрибутов в пункт "Groups".

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

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

Упражнение: ACL обладает интересной возможностью наследования. Все объекты имеют ACL маски по умолчанию (:DEFAULT:). Попробуйте поменять их. Но будьте внимательны, если вы уберете некоторые права из маски офицера безопасности, то потеряете все шансы изменить что-либо в ACL. Придется все удалять и начинать с начала.
 
 

Модуль RC.

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

Здесь вводится такой термин как цели и запросы.
Субъекты (суть процессы )делают запросы на доступ к цели. Запросы могут быть самые разнообразные и совпадают с правами  ACL. То есть вообще-то это одно и то же: есть запрос CHDIR(Можно ли мне сменить каталог на ...) и есть право ALC(можно со мной это делать или нет).
Целью может быть:

• FILE-Файл
• DIR-Каталог
• DEV-Устройство
• IPC - Объект IPC: семафоры, разделяемая память и т.д.
• SCD- Системные данные, такие как имя машины, системный журнал . Все они как правило только для чтения.
• USER-Пользователи
• PROCESS-Процессы
• NONE-Пустой объект
• FD-Файловый дескриптор

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

• Name - Название роли
• Role Comp-Совместимые роли. То есть роли на которые данная роль может переключиться без смены владельца.
• Admin Roles -Роли которые данная роль может администрировать.
• Assign Roles -Роли которая данная роль может назначать пользователям или процессам.
• Type comp FD- Здесь указываются какие ACL права имеет данная роль при обращении к тому или иному подтипу типа FD.
• Type comp DEV-Аналогично для типа DEV.
• Type comp Process-Аналогично для типа Process.
• Type comp IPC-Аналогично для типа IPC.
• Type comp SCD-Аналогично для типа SCD.
• Admin Type-устаревший параметр, указывающий тип этой роли: Системный Администратор, Ролевой Администратор(Офицер безопасности) или Простой Пользователь. Можно вместо него пользовалься первыми четырьмя параметрами. Тем не менее он работосопособен и может спокойно использоваться.
• Default FD Create Type-При создании объекта типа FD будет использован соответствующий подтип. То есть, например, может быть роль создающая только Секретные файлы и Каталоги. Пользоваться которыми смогут только роли с соответствующими ACL правами.
• Default Process CreateType-аналогично для создаваемых (клонируемых) процессов.
• Default Process Chown Type-Подтип процесса после смены владельца (setuid)
• Default Process Execute Type-Подтип процесса после запуска.
• Default IPC Create Type-Подтип новых IPC каналов, семафоров и т.д.

Для примера расскажу как настроить систему так, чтобы администратор мог добавлять пользователей, задавать им пароли, удалять их и при этом не сможет вручную отредактировать /etc/passwd или /etc/shadow. Такой фокус может быть полезен для организации Web-сайта. Когда никто кроме Apache не сможет работать с файлами из определенного каталога. Соответственно, даже прорвавшись в систему, злоумышленник не сможет поменять первую страницу.

Итак, заводим новый подтип цели FD - Passwd FD. Делается это с помощью программы rsbac_menu и пункта меню "RC Types". Вас спросят какой тип цели вам нужен. Выбирайте FD и вперед.
Следующим этапом заводим новую роль Admin Passwd. Для этого заходим в меню "RC Roles". выбираем готовую роль ''System Administrator" (требуемый пункт меню ''Rolelist: Choose role from list"), копируем ее содержимое в новую роль (пункт "Copy Role (New Role)") и называем ее "Admin Passwd".
Сразу отметим, что как только добавился новый подтип цели FD. Так сразу появились для него соответствующие ACL права во всех ролях, причем по умолчанию пустые. Теперь пользователи всех старых ролей не смогут читать файлы подтипа Passwd FD. Подправим новую роль так, что она сможет делать с выше указанным подтипом все. Включим все ACL права для него какие только найдем. Отлично. Формальная подготовка окончена, теперь осталось только произвести соответствующие назначения для файлов и программ.
 

Зайдите в систему как root на одной консоли и как secoff на второй, почему это так важно будет ясно чуть попозже. Заходим в настройку основных параметров файла (как делалось ранее для каталога acltest и файла mactest) выбираем файл /etc/passwd и находим параметр

• RC Type FD - подтип этого дескриптора согласно модели RC.

Следующим шагом будет усилении роли программ. Да, именно программ, а не пользователей. В этом как раз и заключается основная изюминка этого метода. Вновь идем в меню настройки параметров файла (теперь для файла /bin/login)и на этот раз ищем параметр:

• RC Force Role- Роль которую приобретет файл при запуске вне зависимости от того какая роль была первоначально у человека делающего запуск. Это аналогично Suid для обычных UNIX прав.

Другие интересные модули RSBAC.

Модуль FF.

/bin
/sbin
/usr/bin
/usr/sbin

Теперь все пользователи могут запускать программы, необходимые для их работы, но не смогут их удалить. Интересная возможность - отмена наследования для конкретного файла путем отмены флага  "add_inherited" . Можно воспользоваться этим при создании каталогов  только для чтения ("read_only" ) (например /etc) с изменяемыми файлами(например  /etc/mtab).

Полный список прав:

• no_execute -можно назначить этот флаг на каталог /home и теперь пользователи не смогут запускать самостоятельно собранные программы без ведома администратора безопасности.
• secure_delete - применять к файлу безопасное удаление.
• write_only - защита файла от чтения (интересно применить для файлов журналов)
• search_only - полезно только для каталогов. Полное закртие каталога от проникновения.
• execute_only-только запуск.
• read_only-только для чтения.

Важный момент: Если вы включите "FF Role Protection" при конфигурировании ядра,то потяряете возможность входа в систему как администратор безопасности. FF будет запрещать смену владельца с администратора системы на администратора безопасности. Вам следует зайти как обычный пользователь, а затем сменить владельца (su) на администратора безопасности.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Интересный момент:Параметр "Role Protection" появился в ранних версиях RSBAC когда еще не было модуля AUTH. Возможности обеспечиваемые этим параметром абсолютно одинаковы для всех модулей RSBAC и работает аналогично тому как было описано для FF.

Правда  RC использует свои собственные  rc_role, вместо system_role, и поэтому вы можете добавить промежуточнцую роль (единственная с которой можно переходить или на которую можно переходить)в процессе сборки.По умолчанию это 0, предопределенная роль  "General_User" (обычный пользователь).

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

Заключение.

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

• Оказывается можно на лету добавлять свои модули принятия решений. Они выполняются в виде драйверов ядра со специальным интерфейсом.Требуется включение модуля REG при конфигурировании ядра.
• Модули можно на лету включать и отключать (см. пункт меню "Switch Modules"). Не забудьте влючить соответствующий пункт при сборке ядра.
• Можно попробовать перемещать каталог с базой данных и переименовывать, изменяя его имя в файле /usr/src/linux/include/rsbac/aci_data_structures.h. Не забудьте после этого пересобрать ядро. Более того, используя разные названия вы можете запускать разные конфигурации RSBAC.
• А можно вообще создать свой собственный модуль защиты.

Партнёры:

Хостинг: