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 части (ибо на хабре длинные топики не приветствуют), плюс дополнить его информацией о состоянии дел на текущий момент (но кардинально ничего с тех пор не изменилось, просто мелких проблем стало меньше).
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 15
    • +1
      Спасибо. Прочитал сначала следующую статью, и показалось, местами, неясно. Теперь многое стало на свои места. Сам пользую генту, но слышал о selinux и пр только по USE-флагам =). Как раз собираю сейчас домашний сервер под генту, и статья будет оч полезной.
      • 0
        это в основном для домашних пользователей или для серверов?

        Если для серверов - зачем им драйвера Nvidia и xmms? Если для декстопов - разве у линукс и так не всё в порядке с безопасностью?
        • +1
          >разве у линукс и так не всё в порядке с безопасностью?
          Но ведь нам "все в порядке" не подходит. Нам надо "все отлично!". Тем более в линкс все в порядке, лишь до тех пор, пока не ставится дырявый софт, а в десктопном софте довольно часто находят уязвимости. Тем более если есть возможность повысить безопасность на пордок, почти бесплатно, так почему бы и нет?
          • 0
            ну... Не совсем бесплатно. Откатываемся на чуть более раннюю версию компилятора и т.д.
            Согласен, "почему бы и нет". Но я лично бы не стал запариваться.
            • +1
              Потому и написал "почти бесплатно", учитывая в т.ч. и время затраченное на настройку. В моем случае (сервак домашний) вполне допустимо иметь задержку версий компилятора некоторую и, как ниже написали, потерю производительности до 7%. Вот с отставанием ядра - немного тоскливее, т.к. бывают и в нем критические заплатки, но думаю этим можно пожертвовать.
          • 0
            Это и для домашних, и для серверов. Просто с серверами проще, а у домашних куча дополнительных проблем, влияющих на безопасность не лучшим способов: например, вынужденная поддержка подгрузки модулей в ядро из-за использования VMware, бинарные дрова nVidia/ATI (которые никто не компилировал с PIE/SSP), etc.
          • 0
            Как насчет влияния этих фич на производительность?
            По мануалам RedHat включение SELinux стоит примерно 7% производительности.
            • 0
              Ответ в четвёртой части статьи. :)
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                Я это понимаю, но... Кому это интересно - те прочитают. Или найдут позже через поисковики. Меня на хабре интересует обмен информацией, а не зарабатывание очков.

                Так что публиковать статьи я буду тогда, когда они написаны, а не дождавшись "часа пик" на хабре и цедя статьи по капле ровно раз в неделю, для максимального эффекта.
                • 0
                  спасибо за Ваши статьи.
                  сейчас только бегло просмотрел, в понедельник на работе почитаю внимательно :)
                  гентушнику с многолетним стажем, каковым я являюсь, будет полезно почитать про ветку Hardened :) (хоть и был у меня сервак на Gentoo с харденед профайлом, но я особо им не занимался, были еще два админа)
              • 0
                не проще обновляться вовремя и поставить фаервол ?
                >Ограничение прав процессов и юзеров, в т.ч. (я бы даже сказал - в основном) юзера root:
                ну а зачем *? :(
                > и хакер получит "root", то ЭТОТ "root" сможет делать только вышеперечисленные операции...
                поставьте на пользователя root (и на групу) какойто левый UID 999 к примеру
                а вместо рута поставьте adm или типа того -) и даже если хакер будет за вашей машиной - на это посмотреть будет весело
                • 0
                  > не проще обновляться вовремя и поставить фаервол ?

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

                  > ну а зачем *? :(

                  Зачем ограничивать root описано в примере, приведённом в статье. Взлом сервиса, работающего с правами root, не приведёт к захвату всей системы. Обыкновенная многоуровневая оборона, ничего нового.

                  > поставьте на пользователя root (и на групу) какойто левый UID 999

                  Весело будет хакеру, а не админу. Трюк со сменой UID давно всем известен. Гораздо проще использовать цифровой UID 0, чем текстовый root. А 0 Вы на что-то другое не поменяете - слишком много софта рассчитывает, что 0 - это суперпользователь. К тому же после взлома сервиса, работающего под root, хакер уже имеет полномочия суперпользователя, и ему пофиг, какой у него UID и имя.
                • 0
                  Прочитал данную статью ни 1 раз. Идея понравилась. Пробую осуществить. Я пока новичок в Gentoo - тока 2 недели мучаю. Ставлю версию 2008.0 B2. И вот в чем вопрос - чем отличаются профили
                  hardened/x86/2.6 [5]
                  hardened/linux/x86 [13]
                  ?
                  Перекл. на [5], там совсем мало флагов стоит, на [13] побольше. Логически мне понравился больше [13], пока играю с ним. Статья указывает [5]. Есть ли между ними отличия по набору софта или тока базовые флаги?
                  Спасибо
                  • 0
                    Не думаю, что есть какие-то принципиальные отличия.
                    Кроме того можно просто сравнить эти профайлы diff-ом и изучить отличия. Если интересно, из каких соображений создали два разных профайла для одной задачи - напишите в mail list gentoo-user-ru@ или gentoo-hardened@, там Вам скорее всего квалифицированно ответят сами разработчики Gentoo.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.