Прежде чем мы начнем с вами превращать свой компьтер в неприступную
крепость необходимо сначала разобраться с тем, что вас ожидает. Любая система
безопасности вносит ограничения в вашу деятельность, а серьезная система
вносит очень серьезные ограничения. Дополнительные проверки и авторизации
понижают производительность ядра, а такие вещи как безопасное удаление
понижают скорость работы файловой системы. Забудьте про всесильного суперпользователя,
его всесилие одна из наиболее серьезных проблем безопасности. Теперь у
вас будут отдельно администратор системы (в дальнейшем просто администратор)
и администратор безопасности( в дальнейшем офицер безопасности). Оба не
смогут влиять друг на друга и даже будут конкурировать за власть в системе.
Администратор сможет по-прежнему управлять системой в целом, производить
настройки, заводить и удалять пользователей, ограничивать использование
пользователями системных ресурсов(см. статью "Начала 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 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 и для начала углубляемся в теорию включенных нами моделей безопасности.
Как было сказано ранее, данный модуль контролирует смену владельцев
у процесса, для своего контроля позволяет модифицировать для файла следующие
параметры:
Сразу исправим права у служб которые не пожелали работать. Для начала
заглянем в системные журналы (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 реализует модель мандатного доступа, предложенную в
свое время Беллом и Ла Падулом, поэтому сначала немного сухой теории.
Выделяются отдельно множество объектов 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 принадлежат следующие параметры:
В программе rsbac_menu переходим в меню управления пользователями ("User Attributes: Go to user attribute menu") и с не меньшим удивлением обнаруживаем, что у пользователя дополнительных параметров совсем не меньше чем у файла. Сейчас нас интересуют:
Важный момент: Модуль MAC позволяет производить смену процессу UID пользователя только если уровень секретности текущего пользователя не ниже уровня секретности нового. Это основная проблема того, что администратор (root) всегда имеет максимальный уровень секретности.
Упражнение для разработчиков:
Решите проблему с завышенным уровнем секретности у root'a. Один из
возможных подходов состоит в том, что можно добавить новый аттрибут "Enforced
MAC security level" , аналогично аттрибуту "RC enforced role".
Маловато будет. Мандатный доступ хорош, но хочется чего то большего.
Хочется контролировать права доступа у файлу с точностью до миллиметра,
с точностью до пользователя или группы пользователей.
Для этого мы включили модуль 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. Придется
все удалять и начинать с начала.
Вы любите театр? Если это так, то понять суть ролевого механизма
для вас не составит особого труда. Для всех остальных придется немного
поглубже вникнуть в идеологию системы 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 и находим параметр
Следующим шагом будет усилении роли программ. Да, именно программ, а не пользователей. В этом как раз и заключается основная изюминка этого метода. Вновь идем в меню настройки параметров файла (теперь для файла /bin/login)и на этот раз ищем параметр:
/bin
/sbin
/usr/bin
/usr/sbin
Теперь все пользователи могут запускать программы, необходимые для их работы, но не смогут их удалить. Интересная возможность - отмена наследования для конкретного файла путем отмены флага "add_inherited" . Можно воспользоваться этим при создании каталогов только для чтения ("read_only" ) (например /etc) с изменяемыми файлами(например /etc/mtab).
Полный список прав:
Важный момент: Если вы включите "FF Role Protection" при конфигурировании ядра,то потяряете возможность входа в систему как администратор безопасности. FF будет запрещать смену владельца с администратора системы на администратора безопасности. Вам следует зайти как обычный пользователь, а затем сменить владельца (su) на администратора безопасности.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Интересный момент:Параметр "Role Protection"
появился в ранних версиях RSBAC когда еще не было модуля AUTH. Возможности
обеспечиваемые этим параметром абсолютно одинаковы для всех модулей RSBAC
и работает аналогично тому как было описано для FF.
Правда RC использует свои собственные rc_role, вместо system_role, и поэтому вы можете добавить промежуточнцую роль (единственная с которой можно переходить или на которую можно переходить)в процессе сборки.По умолчанию это 0, предопределенная роль "General_User" (обычный пользователь).
Эта функциональная возможность вносит гораздо
больше ограничений нежели безопасности, поэтому по-умолчанию, при конфигурировании
ядра она выключена, а взамен используется AUTH.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
В данном руководстве были рассмотрены далеко не все модули. Это
объясняется в первую очередь нежеланием засорять мозги читателей лишней
информацией. Если это будет необходимо, то появятся новые серии руководств.
Но все же вкратце остановлюсь на некоторых интересных моментах предполагающих
дальнейшее изучение.
Хорошее должно продолжаться.