Hardened Gentoo: описание

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

Hardened Gentoo — это несколько изменений в компиляторе и ядре, которые увеличивают общую защищенность системы от взлома. Например, hardened-ядро умеет блокировать массу потенциально опасных операций, а hardened-gcc позволяет защитить компилируемые им программы от взлома типовыми методами а-ля переполнение буфера. Грубо говоря, если у вас стоит «дырявая» версия программы X, и её пытается взломать хакер, то в обычной системе у него это получится, а в hardened — не получится, да ещё и в лог запись пойдёт.

Для установки Hardened на обычный Gentoo нужно будет полностью перекомпилировать всю систему — иначе защиты предоставляемые hardened-gcc не будут использоваться. Hardened — это ещё одна система, которую нужно аккуратно настраивать — переборщишь с защищённостью — ничего работать не будет вообще, недоборщишь — зачем тогда вообще Hardened ставить? Некоторые проги с hardened не уживаются (обычно это бинарные пакеты: дрова nVidia/ATI, Java плюс почему-то такой софт как mplayer/xmms) — это не смертельно, просто приходится для этих прог индивидуально отключать часть защит (для этого есть утилитки)… что огорчает. Ядро используется из пакета hardened-sources, и оно обычно на пару версий отстаёт от gentoo-sources.

Итак, Hardened Gentoo это просто объединение нескольких разных, часто независимых друг от друга, проектов:

1. Hardened toolchain — специальные патчи на gcc/glibc/binutils:
   
   • SSP — добавляет в бинарник защиту от переполнения буфера, т.е. прога откомпилированная с SSP сама проверяет что у неё не переполнили буфер и киляет сама себя если обнаруживает переполнение (как следствие бага в самой программе или попытки её взломать эксплойтом).
   • PIE — не увеличивает защищённость сам по себе, но приводит к генерации более гибкого кода, благодаря чему его можно будет защитить на уровне ядра через PaX.
   
   PIE и SSP не зависят друг от друга, и их можно использовать вместе и по отдельности (после компиляции hardened toolchain можно будет через gcc-config переключаться между всеми вариантами — PIE+SSP, только PIE, только SSP, ничего (т.е. обычный gcc) — например, если какая-то прога не будет компилироваться.
2. Патчи на ядро. Их бывает много, и разных, :) но в Gentoo есть поддержка только четырёх из них — PaX, SeLinux, GrSecurity и RSBAC. Функциональность они добавляют трех типов:
   
   1. Защита от переполнения буфера (а-ля SSP но со стороны ядра и другими методами, так что они друг друга дополняют): PaX. Например, PaX позволяет запретить выполнение кода в страницах памяти с данными (софтварная реализация NX-бита, которые появился только в 64-битных процах Intel) — PaX просто кильнёт процесс если он попытается нарушить эту защиту; при загрузке программы в память грузит все её функции по случайным адресам, чтобы эксплойту было очень сложно узнать на какой адрес передавать управление (это становится возможным благодаря компиляции с PIE).
   2. Отключение потенциально опасных «фич» ядра: GrSecurity, RSBAC. Пример: запрет выполнять mount внутри chroot — чтобы хакер взломавший chroot-нутый демон и получивший root-а не смог выйти из chroot.
   3. Ограничение прав процессов и юзеров, в т.ч. (я бы даже сказал — в основном) юзера root: SeLinux, GrSecurity/RBAC, RSBAC. Здесь идея в том, что админу (вам :)) нужно подготовить список с указанием какие проги/юзеры что имеют право делать. Пример: можно ограничить root-овый процесс apache из всех прав root-а только возможностью садиться на 80-й порт и читать файлы в /etc/apache2/. В этом случае даже если его и взломают, и хакер получит «root», то ЭТОТ «root» сможет делать только вышеперечисленные операции… хакер будет крайне разочарован. :)
   
   Эти три «фичи» тоже не зависят одна от другой. Но сами патчи — SeLinux, GrSecurity и RSBAC обычно между собой не совместимы и нужно использовать только один из них. Впрочем, в Gentoo сумели объединить SeLinux и GrSecurity вместе. Часть GrSecurity, которая занимается третьей фичей (ограничением прав) называется RBAC, и её использовать вместе с SeLinux нельзя — или-или.
   Итого, варианты есть, например, следующие:
   
   • PaX + GrSecurity
   • PaX + GrSecurity (без RBAC) + SeLinux
   • PaX + SeLinux
   • PaX + RSBAC
   • … etc ...
   
   Я выбрал первый (PaX+GrSecurity) т.к. во-первых настройка SeLinux обещает быть кошмаром, в отличие от GrSecurity/RBAC; во-вторых на мой взгляд поддержка RSBAC в Gentoo ещё сыровата; и в-третьих ну понравился мне GrSecurity, понравился. :))

Продолжение следует...

Note: Часть текста была написана больше двух лет назад, и публиковалась в maillist gentoo-user-ru. Я хочу разбить текст на 4 части (ибо на хабре длинные топики не приветствуют), плюс дополнить его информацией о состоянии дел на текущий момент (но кардинально ничего с тех пор не изменилось, просто мелких проблем стало меньше).