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 это просто объединение нескольких разных, часто независимых друг от друга, проектов:
- Hardened toolchain — специальные патчи на gcc/glibc/binutils:
- SSP — добавляет в бинарник защиту от переполнения буфера, т.е. прога откомпилированная с SSP сама проверяет что у неё не переполнили буфер и киляет сама себя если обнаруживает переполнение (как следствие бага в самой программе или попытки её взломать эксплойтом).
- PIE — не увеличивает защищённость сам по себе, но приводит к генерации более гибкого кода, благодаря чему его можно будет защитить на уровне ядра через PaX.
PIE и SSP не зависят друг от друга, и их можно использовать вместе и по отдельности (после компиляции hardened toolchain можно будет через gcc-config переключаться между всеми вариантами — PIE+SSP, только PIE, только SSP, ничего (т.е. обычный gcc) — например, если какая-то прога не будет компилироваться. - Патчи на ядро. Их бывает много, и разных, :) но в Gentoo есть поддержка только четырёх из них — PaX, SeLinux, GrSecurity и RSBAC. Функциональность они добавляют трех типов:
- Защита от переполнения буфера (а-ля SSP но со стороны ядра и другими методами, так что они друг друга дополняют): PaX. Например, PaX позволяет запретить выполнение кода в страницах памяти с данными (софтварная реализация NX-бита, которые появился только в 64-битных процах Intel) — PaX просто кильнёт процесс если он попытается нарушить эту защиту; при загрузке программы в память грузит все её функции по случайным адресам, чтобы эксплойту было очень сложно узнать на какой адрес передавать управление (это становится возможным благодаря компиляции с PIE).
- Отключение потенциально опасных «фич» ядра: GrSecurity, RSBAC. Пример: запрет выполнять mount внутри chroot — чтобы хакер взломавший chroot-нутый демон и получивший root-а не смог выйти из chroot.
- Ограничение прав процессов и юзеров, в т.ч. (я бы даже сказал — в основном) юзера 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 части (ибо на хабре длинные топики не приветствуют), плюс дополнить его информацией о состоянии дел на текущий момент (но кардинально ничего с тех пор не изменилось, просто мелких проблем стало меньше).