11 августа 2007 в 08:13

Hardened Gentoo: впечатления

Я начал с того, что выразил желание развеять распространённые опасения в том, что Hardened — это слишком сложно, либо от этого cтрадает стабильность, функциональность или производительность системы. Я уже продемонстрировал, что такое Hardened Gentoo в общих чертах, а теперь пройдёмся детальнее по этим опасениям.

Сложность


Я пока не занимался настройкой системы ролей (RBAC/SELinux) как раз из-за сложности. Возможно, конечно, только кажущейся, и на самом деле там тоже всё просто, не знаю… :) Я, всё-таки, в основном программист, и на администрирование времени вечно не хватает. В общем, если в Hardened и есть что-то сложное и требующее кучу времени и внимания — это настройка ролей.

А вот всё, что я описал до этого, настраивается очень просто, быстро, один раз, и даёт достаточно сильный эффект в виде усиления безопасности системы!

Стабильность


Я уже много лет использую Hardened в описанном виде и дома на workstation, и на всех серверах. Никаких проблем со стабильностью их работы из-за Hardened за это время не возникало, и я не видел жалоб в maillist на эту тему.

Что касается стабильности сборки Gentoo, ведь пакеты постоянно обновляются и компилируются. Пару лет назад была необходимость использовать некоторые workaround-ы — например, чтобы XWindow работали с дровами ATI приходилось их собирать не-hardened gcc (для автоматического переключения gcc в процессе компиляции пакетов был написан простейший скрипт). Ну и ещё по мелочи проблем возникало, но ни одной критичной. Сейчас проблем такого рода нет в принципе. Т.е. вы систему на Hardened перевели, и забыли — можете продолжать всё делать так, как будто ничего не произошло. Только хакать ваш сервер стало сложнее гораздо. :)

Функциональность


Да, для того, чтобы работали некоторые пакеты, до сих пор необходимо использовать утилиты chpax/paxctl, для отключения части hardened-защит для конкретных приложений.

Но в Gentoo эта операция давно автоматизирована: для этих приложений chpax/paxctl выполняется на этапе установки пакета. Так что вам об этом беспокоиться уже не нужно.

А за исключением этого нюанса (что для некоторых приложений часть защит выключена), все приложения работают в Hardened Gentoo без проблем (по крайней мере с теми настройками ядра, которые я привёл в предыдущей части).

Производительность


Честно скажу — сам я не мерял. Да и что и как мерять — не совсем понятно. Насколько я понял из инета — можно ожидать до 3-4% потери производительности в худшем случае, а обычно это будет меньше процента.

Но, опять-же, смотря какие «фичи» включать. Если врубить SeLinux или RBAC — тогда можно эти 3-4% потерять, но до их настройки я пока не добрался. :(

Визуально — после перехода на Hardened разницы никакой, ни на домашней машине, ни на серверах.

Конечно, сколько-то производительности, вероятно, было потеряно из-за перехода на -O2.

Ещё я сталкивался с тем, что при выборе «неправильной» опции при настройке ядра из этих двух:
[ ] Paging based non-executable pages
[*] Segmentation based non-executable pages

возникали заметные тормоза. Сейчас я в ядре вообще не вижу первого варианта (который любил потормозить на некоторых типах процессоров).

Выводы


В общем, у вас есть реальная возможность значительно увеличить безопасность своих машин, потратив один раз пару часов вашего времени на переход на Hardened и сутки машинного времени (пока будет полностью пересобираться система).

«Думайте сами, решайте сами — иметь, или не иметь.» :)

Начало. Вторая часть. Третья часть.
Alex Efros @powerman
карма
303,5
рейтинг 0,0
Systems Architect, Senior Go/Perl Linux Developer
Похожие публикации
Самое читаемое Администрирование

Комментарии (13)

  • 0
    "сутки машинного времени (пока будет полностью пересобираться система)."
    - сильно. чего ради собирать сутками систему?
    • +2
      Gentoo - это source based дистрибутив, что означает что все программы компилируются на вашей машине (хотя если у вас много одинаковых машин, то можно скомпилировать все пакеты на одной, а на остальные из поставить так же, как ставятся rpm-ки). Это имеет свои плюсы и минусы.

      Плюсы, помимо возможностей по оптимизации, контроля за тем, что и как компилировать, etc., в том, что полностью уходит проблема "rpm hell": никакой больше несовместимости между устанавливаемым приложением и имеющимися библиотеками.

      Минусы - переодически нужно тратить машинное время на компиляцию. Если у вас сервер загружен на 80-100%, то регулярные компиляции отрицательно скажутся на его производительности. Но такие сервера - редкость. Обычно то, что сервер иногда что-то компилирует, абсолютно не заметно.

      Что касается необходимости пересбора всей системы. Патчи на gcc (SSP и PIE) на конкретное приложение повлияют только тогда, когда этим, пропатченным gcc это приложение будет перекомпилировано. Поэтому и нужно пересобирать всю систему. Кроме того, возможность пересборки всей системы очень полезна при обновлении toolchain - ключевых пакетов типа linux-headers, glibc, gcc, binutils. Если вы хоть раз обновляли glibc на rpm-based дистрибутиве, то должны знать, чем это обычно заканчивается для системы... а в Gentoo это абсолютно обычная, рядовая и безопасная операция, только очень желательно не полениться и пересобрать систему. В конце концов - оно же само всё делает, мне педали крутить не нужно...

      Вообще, сборка из исходников, это единственный идеологически корректный способ установки приложений в *NIX. Установка бинарных пакетов типа rpm либо накладывает кучу ограничений, либо (со временем) приводит к куче проблем.
      • +2
        мне с последним абзацем трудно согласится. Никаких особых явных ограничений (а особенно кучи их) в установке rpm я не наблюдаю на моих ~80 RHEL серверов, да и кучи проблем, за последние 6 лет использование пакетных дистрибутивов для сурового продакшин, как-то тоже не детектирую. Что касается "rpm hell" то решать эту проблему пересбором всех зависимых пакетов это конечно несколько экстремальный способ. Однако, автоматическое решение зависимостей, наряду с сосуществованием нескольких версий rpm, уже давно придумано и используется.
        • +2
          Я с rpm последний раз сталкивался во времена RedHat 7.0. Если с тех пор что-то кардинально изменилось, то было бы любопытно об этом узнать/где-нить почитать. А в те времена ситуация была такая, как я описал.
          • 0
            да-да. именно намучившись в свое время с rpm-пакетами в RH7, перешел на gentoo.

            спасибо за серию статей, занимательно.
          • 0
            в 2007 брать за отрицательный (базовый) пример систему года 99 (или 2000) мне кажется несколько некорректно. Примерно так же прозвучало бы, если сказать "на пакетных дистрибутивах приходитсся жить под ядром 2.2 с мучениями, а вот на генту свежое 2.6". Это я к тому клоню, что не только ядро с 99 года развивалось ;)
            • 0
              Ох... неужели уже столько лет прошло...

              А можно немного конкретнее? Что именно такого критичного изменилось в rpm за эти годы?

              Если в него добавляют ещё больше метаинформации по зависимостям и он делает ещё больше проверок при установке пакета, то это тупиковый подход. Установка бинарных пакетов будет стабильно работать только при условии, что при сборке этого пакета была известна полная информация о системе, куда его будут ставить. А это возможно только в том случае, если все системы полностью идентичны: ставится некоторая базовая система "от производителя", после чего на неё устанавливаются ВСЕ обновлнения "от производителя", исключительно в том порядке, в котором они выпускаются, и не устанавливаются никакие другие приложения. А так в реальной жизни - не бывает. Возможно, сейчас эти проблемы возникают значительно реже... но достигается это наверняка за счёт дополнительного усложнения, подпорок и workaround-ов. Эти проблемы есть везде, где устанавливаются бинарные пакеты, в т.ч. и под виндой.
              • +1
                по поводу что изменилось, могу невежливо послать в гугл, он рулит :) По поводу теоретического обоснования, мне опять трудно спорить, т.к. мы похоже расходимся по базовым принципам и видимо по опыту практическому. Так например, для меня совершенно не очевидно (я даже считаю это неверным) утверждения про "стабильную работу" и мне совершенно не кажется верным тезис о необходимости установки обновлений в "правильном порядке" (видимо по мнению автора так решают зависимости в rpm-based дистрибутивах), но я не спорить пришел сюда в комментарии. Согласитесь мне, мало знакомому с современнным состоянием генту, спорить с автором, мало знакомым с rpm 21го века, как-то даже странно. Я пришел заронить зерно сомнения на почву, так сильно политую (заметьте не удобренную ;) вашими очень уверенными ответами и намекнуть неискушенному читателю, что не все так очевидно.
                • +1
                  :) ok, в гугл, так в гугл.
        • 0
          Соглашусь с посмотреть профиль powerman относительно идеологической правильности сборки из исходников.
          Дело в том, что кроме оптимизации под целевую систему (этот аргумент используют очень часто, когда говорят о source-based дистрибутивах), сборка из исходников позволяет осуществить очень тонкие настройки приложения. Примером тому может служить jabberd, при компиляции которого можно указать СУБД, с которыми он сможет работать. Binary-based дистрибутивы очень часто за пользователя определяют настройки сборки, тогда как source-based - позволяют полностью раскрыть этот потенциал и обеспечить максимальную гибкость системы.
  • 0
    намучавшись с тормозными пакетами rpm и длительной сборкой всего из исходников - перешёл на deb
    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      У меня дома вся система (workstation, т.е. значительно больше софта, чем на сервере) пересобирается за 7 часов (причём я в процессе на ней работаю и этого не чувствую - компиляция запускается под nice). Так что рекомендую: Core2Duo 6600, и из исходников всё будет собираться быстрее, чем можно себе представить. :)

      А если серьёзно, то когда у меня был Athlon XP 1800, я просто оставлял машину компилировать на ночь, и "длительной сборки всего из исходников" просто не замечал. Да и вообще, не так уж часто в Gentoo приходится много компилировать, разговоров об этом значительно больше, чем дела.

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