Re: [OBORONA-SPAM] Re: [gentoo-user-ru] hardened

[Alex Efros]

Hi!





Краткое описание что подразумевается под "Hardened Gentoo" и что оно даёт.

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.

  Функциональность они добавляют трех типов:

  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, понравился. :))



Итого, процесс выглядит следующим:

- переключаемся на hardened toolchain и пересобираем им всю систему,

  чтобы все бинарники использовали PIE и SSP (после этого система

  становится защищена SSP)

- устанавливаем hardened-sources (они содержат патчи PaX + GrSecurity +

  SeLinux + допольнительные от Gentoo) и компилируем их с поддержкой

  PaX, GrSecurity и GrSecurity/RBAC

- перегружаемся с новым ядром (после этого система становится защищена

  ещё и PaX+PIE и GrSecurity)

- некоторое время настраиваем и отлаживаем ограничения доступа (после

  чего система становится защищена ещё и GrSecurity/RBAC)



Ожидаемые проблемы:

- не всё может скомпилироваться с PIE+SSP - возможно отдельные пакеты

  нужно будет патчить или компилировать без одной или обоих из них

  (мне пока потребовалось через gcc-config переключаться на vanilla gcc

  только для компиляции X-ов чтобы они работали с ATI-дровами)

- не всё может нормально работать, т.к. некоторые программы (обычно

  упоминают X-ы и java) используют выполнение динамически

  сгенерированного кода для вполне легальных целей, а теперь при попытке

  это делать они будут киляться либо SSP либо PIE+PaX - для этих

  программ нужно будет индивидуально отключать часть защит PaX (для этого

  есть специальные утилиты, например paxctl) и/или компилировать их без SSP

- не всё может работать из-за ограничений "фич" ядра GrSecurity - в этом

  случае нужно будет часть защит GrSecurity отключать (глобально, в

  make menuconfig)

- настроить ограничения прав доступа может оказаться не просто, и в

  любой момент когда какая-нить прога сделает что-то, что мы при

  настройке её прав не учли - она будет прибита ядром... и придётся

  эти правила в срочном порядке фиксить





Ну что, поехали... :)



Слишком сильная оптимизация (-O3) вместе с hardened toolchain может

приводить к разным глюкам и сбоям компиляции, поэтому нужно в

/etc/make.conf заменить -O3 на -O2.



Переходим на hardened-профайл. (Теоретически вместо этого можно было просто

добавить в USE-флаги: "hardened pie ssp".)



    ln -snf ../usr/portage/profiles/hardened/x86/2.6/ /etc/make.profile

    

После переключения профайла на hardened/x86/2.6/ выключилось несколько

нужных мне USE-флагов, которые в обычных профайлах включены

автоматически - я их дописал в make.conf:

    avi encode gtk2 jpeg mpeg oss quicktime spell truetype xv

    bitmap-fonts truetype-fonts type1-fonts



Компиляция hardened-toolchain и пересборка им всех остальных пакетов:



    emerge binutils gcc glibc

    emerge -e world

    dispatch-conf



Далее, нужно поставить ещё несколько пакетов:



    emerge paxtest paxctl gradm



paxtest можно было поставить и раньше, до перехода на hardened toolchain.

Эта утилитка пытается делать разные опасные операции (типа переполнения

стека с выполнением кода), которые обычно выполняют эксплойты. Если

система защищена, то все её попытки будут пресечены, о чём она и сообщит.

В общем, можно её погонять до установки hardened toolchain, после а

так-же после перезагрузки с ядром где включён PaX, по приколу. :)



paxtest как свою зависимость так-же установит прогу chpax - это вроде

старый способ управлять PaX, вместо которого лучше использовать paxctl.

Но некоторые проги, распространяемые без исходников, скомпилированы так,

что paxctl с ними работать не может, и приходится юзать chpax.



Ну а gradm нужен для настройки RBAC в GrSecurity - тех самых ограничений

прав для процессов и юзеров.



Что касается настроек ядра. Я для начала настроил всё так, как описано в доке

Gentoo и GrSecurity - при этом не все защиты включены, но 

большинство софта при таких настройках будет работать. В процессе

разбора с настройками возникло несколько теоретических предположений:



    Если загрузить hardened ядро ДО перекомпилирования системы, то могут

    возникнуть проблемы если включена эта опция:



    PaX -> Non-executable pages -> Disallow ELF text relocations



    На сервере, где нет X-ов, можно дополнительно включить: (не забыть

    перед этим проверить, что от этого не перестало работать что-то

    кроме X-ов, в частности hwclock):

    

    Grsecurity -> Address Space Protection -> Disable privileged I/O



    Кроме того, ещё есть предположение, что некоторые ограничения chroot

    могут помешать операциям типа инсталляции Gentoo (которая идёт внутри

    chroot) или попытке починки системы (если, например, для этого 

    загрузиться с CD с таким hardened ядром):



    Grsecurity -> Filesystem Protections -> Deny mounts

    Grsecurity -> Filesystem Protections -> Deny double-chroots

    Grsecurity -> Filesystem Protections -> Deny (f)chmod +s

    Grsecurity -> Filesystem Protections -> Deny mknod





-- 

			WBR, Alex.

-- 

gentoo-user-ru@g.o mailing list