Начала RSBAC.

Автор: Stanislav Ievlev <inger@linux.ru.net> Оригинал документа: linux.ru.net

Введение.


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

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

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

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

1. основной код -rsbac-версия.tar.gz или rsbac-версия.tar.bz2
2. утилиты администрирования - rsbac-admin.tar.gz
3. заплатка к ядру
 

Возьмите последнюю версию системы 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 имеет модульную структуру, то есть существует несколько модулей аутентификации, каждый из которых контролирует доступ своим особым способом. Окончательное решение о предоставлении доступа или отказе в нем получается как суммарное после обсуждения этого вопроса всеми модулями. Все модули работают независимо, за исключением модуля auth, который используется всеми. Все модули включать нет смысла (сравните десять судей будут думать над приговором или три) и мы ограничимся рассмотрением только самых интересных. Для начала краткая информация о каждом, детали выясняться позже при реальной работе. Оставьте выше указанные модули, остальные выключите. В каждом из влюченном убедитесь, что включены только "ИМЯ-МОДУЛЯ protection for AUTH module" и ничего больше.

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


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


Сразу исправим права у служб которые не пожелали работать. Для начала заглянем в системные журналы (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, с учетом имени пользователя и его группы.

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

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

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

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

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

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

Важный момент: Модуль 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" и ... вам хватит этого?

Уфф... кажется все. Потом на досуге вы конечно попробуете включать/выключать все аттрибуты, а мы пока для примера отменим один.

Выключим для каталога ~/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(можно со мной это делать или нет).
Целью может быть:

Причем каждый тип цели может иметь сой подтип. Например, файл может быть Обычный, Секретный или Системный.

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

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

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

И изменяем значение по умолчанию на Passwd FD.  После этого как бы root ни пытался он уже не в состоянии ничего сотворить в этим файлом. На этом этапе ни в коем случае не выходите из системы, login тоже пока не имеет прав на чтение /etc/passwd и соответственно никого принять не сможет.

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

Меняем ее значение со стандартного на "Admin Passwd". После проделанной операции login заработает нормально (на всякий случай проверьте это на отдельной консоли не выходя полностью из системы). Аналогичную процедуру надо повторить для всех программ работающих с файлом /etc/passwd. Вот и все, новый защитный барьер готов.
 

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

Модуль FF.

Это Самый простой до гениальности модуль .Пользуясь им вы можете легко назначать аттрибуты целым деревьям каталогов. Например, можно назначить флаг "read_only" (только для чтения) для:

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

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

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

Не правда ли FF очень простой и мощный модуль?

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

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

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

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

Заключение.


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

Пробуйте, развивайте, сообщайте миру о своих результатах.
 
 

Хорошее должно продолжаться.