Сначала я расскажу вам, почему публикую эту статью.
Дело в том, что большинство пользователей Gentoo Linux до сих пор не используют Закаленный Генту .
И вызвано это обычно тем, что они либо не знают, что это такое, либо считают, что это слишком сложно, либо считают, что от этого пострадает стабильность, функциональность или производительность системы.
Именно эти страхи я хочу попытаться развеять.
Hardened Gentoo включает в себя несколько изменений в компиляторе и ядре, которые повышают общую защищенность системы от взлома.
Например, усиленное ядро может блокировать множество потенциально опасных операций, а Hardened-gcc позволяет защитить скомпилированные им программы от взлома стандартными методами вроде переполнения буфера.
Грубо говоря, если у вас «дырявая» версия программы X, и ее пытается взломать хакер, то в обычной системе у него это получится, а в закаленной это не получится, и это тоже будет записано в журнал.
.
Чтобы установить Hardened на обычный Gentoo, вам потребуется полностью перекомпилировать всю систему — в противном случае защита, предоставляемая Hardened-gcc, не будет использоваться.
Hardened - это еще одна система, которую нужно тщательно настраивать - если переборщить с безопасностью вообще ничего не будет работать, если не переборщить, то зачем вообще ставить Hardened? Некоторые программы не уживаются с защищёнными (обычно это бинарные пакеты: nVidia/ATI, Java плюс почему-то софт типа mplayer/xmms) - это не фатально, просто придётся индивидуально отключить часть защиты для этих программы (для этого есть утилиты).
что огорчает. Ядро взято из пакета Hardened-sources и обычно на пару версий опережает gentoo-sources. Итак, Hardened Gentoo — это просто объединение нескольких разных, часто независимых, проектов:
- Усиленная цепочка инструментов — специальные патчи для gcc/glibc/binutils:
- ССП — добавляет в бинарник защиту от переполнения буфера, т.е.
программа, скомпилированная с помощью SSP, сама проверяет, что ее буфер не переполнен, и убивает себя, если обнаруживает переполнение (в результате ошибки в самой программе или попытки взломать ее с помощью эксплуатировать).
- ПИРОГ — не повышает безопасность сама по себе, но приводит к генерации более гибкого кода, благодаря чему его можно защитить на уровне ядра через PaX.
обычный gcc) — например, если какая-то программа не скомпилируется.
- ССП — добавляет в бинарник защиту от переполнения буфера, т.е.
- Патчи ядра.
Их много, и разные :) но Gentoo поддерживает только четыре из них — Пакс , СеЛинукс , GrSecurity И РСБАК .
Они добавляют три типа функциональности:
- Защита от переполнения буфера (а-ля SSP, но со стороны ядра и другими методами, поэтому они дополняют друг друга): PaX. Например, PaX позволяет запретить выполнение кода в страницах памяти с данными (программная реализация бита NX, появившаяся только в 64-битных процессорах Intel) — PaX просто убьет процесс, если попытается нарушить эту защиту; при загрузке программы в память она загружает все свои функции по случайным адресам, из-за чего эксплойту очень сложно узнать, на какой адрес передать управление (это становится возможным благодаря компиляции с помощью PIE).
- Отключение потенциально опасных функций ядра: GrSecurity, RSBAC. Пример: запрет на выполнение монтирования внутри chroot — чтобы хакер, взломавший chrooted демон и получивший root, не смог выйти из chroot.
- Ограничение прав процессов и пользователей, в т.ч.
(Я бы даже сказал - в основном) пользователь root: SeLinux, GrSecurity/RBAC, RSBAC. Идея здесь в том, что админу (вам :)) нужно подготовить список с указанием какие программы/пользователи что имеют право делать.
Пример: вы можете ограничить процесс root apache со всеми root-правами только возможностью использовать порт 80 и читать файлы в /etc/apache2/.
В этом случае, даже если его взломают и хакер получит «рут», то «ТОТ «рут» сможет совершать только вышеперечисленные операции.
хакер будет крайне разочарован.
:)
Но сами патчи — SeLinux, GrSecurity и RSBAC обычно не совместимы друг с другом и вам нужно использовать только один из них.
Однако Gentoo удалось объединить SeLinux и GrSecurity. Та часть GrSecurity, которая занимается третьей функцией (ограничением прав), называется RBAC, и ее нельзя использовать вместе с SeLinux — либо-или.
Всего есть варианты, например, следующие:
- ПаХ + ГрСекьюрити
- PaX + GrSecurity (без RBAC) + SeLinux
- ПаХ + СеЛинукс
- ПаХ + РСБАК
- .
и т. д.
во-первых, настройка SeLinux обещает быть кошмаром, в отличие от GrSecurity/RBAC; во-вторых, на мой взгляд, поддержка RSBAC в Gentoo пока сырая; и в-третьих, GrSecurity мне понравилась, она мне понравилась.
:))
- Защита от переполнения буфера (а-ля SSP, но со стороны ядра и другими методами, поэтому они дополняют друг друга): PaX. Например, PaX позволяет запретить выполнение кода в страницах памяти с данными (программная реализация бита NX, появившаяся только в 64-битных процессорах Intel) — PaX просто убьет процесс, если попытается нарушить эту защиту; при загрузке программы в память она загружает все свои функции по случайным адресам, из-за чего эксплойту очень сложно узнать, на какой адрес передать управление (это становится возможным благодаря компиляции с помощью PIE).
Примечание: Часть текста была написана более двух лет назад и опубликована в рассылке gentoo-user-ru. Хочу разбить текст на 4 части (ибо длинные темы на хабе не приветствуются), плюс дополнить информацией о состоянии дел на данный момент (но ничего принципиально с тех пор не изменилось, просто мелких проблем стало меньше) .
Теги: #настройка Linux #security #Gentoo #SSP #PIE #pax #grsecurity #hardened
-
Сан-Марино
19 Oct, 24 -
Сетевые Рабочие Места Процветают
19 Oct, 24 -
Создание Партнерских Веб-Сайтов
19 Oct, 24 -
Зачем Писать Ботов Вк На C++?
19 Oct, 24 -
Слог Ос
19 Oct, 24