LINUX.ORG.RU

Часть 1. SELinux. Максимальный уровень защиты – бесплатно


0

0

Пару недель назад в новостях промелькнуло сообщение о том, что Red Hat Enterprise Linux на серверах IBM получил уровень сертификации по безопасности EAL4 Augmented with ALC_FLR.3. Итак, каким же образом обеспечивается соответствие столь высокому критерию безопасности? В немалой степени это стало возможным благодаря SELinux (Security-Enhanced Linux) - реализации системы мандатного контроля доступа (MAC)

>>> Ссылка на блог

★★

Проверено: svu ()

Ответ на: комментарий от phoenix

Не согласен, как вводная часть очень даже хорошо.

Virun
()

Enterprise он на то и есть Enterprise.

xTERM ★★
()

Статья понравилась, как раз о том, что сейчас интересует. Жду продолжения :)

Laz ★★★★★
()

интересно, если SELinux это максимальный уровень защиты, то что же получается при установке RSBAC? )

anonymous
()
Ответ на: комментарий от Virun

>Enterprise НМ МЮ РН Х ЕЯРЭ Enterprise.

нЦН, МЮ РН НР МЕЦН Х РЮЙ Х КЕГСР ДШПЙХ ЙЮЙ БЬХ Х АКНУХ.

SEL ЯЮЛЮЪ МЕСДЮВМЮЪ Х ЛНГЦНЛЕПРБЮЪ ПЕЮКХГЮЖХЪ MAC ЙНРНПЮЪ ЙНЦДЮ КХАН АШКЮ БХДЕМЮ ЛХПНЛ. йЮЙ Х MAC Б ЖЕКНЛ. дЮФЕ РЕ ОПХЯКЮБСРШЕ ЮКЦНПХРЛШ Б БЕМДЕ ЙНХ НАУНДЪР ЙЮЙ ЯКЕОШУ ЙПНРНБ ОН ЯПЮБМЕМХЧ Я МХЛ ОПНЯРН БЕПЬХМЮ БЛЕМЪЕЛНЯРХ Х АЕГНОЮЯРМНЯРХ. еЯКХ УНРХРЕ ЯЕЙЭЧПМНЦН MAC Х АНКЕЕ ЛЕМЕЕ БЛЕМЪЕЛНЦН РН ОНЯЛНРПХРЕ МЮ tomoyo.

MAC ЯЮЛ ОН ЯЕАЕ ЙЮЮЮЯРШКЭ, МЕ СДХБКЧЯЭ ЕЯКХ КХМСЙЯ ОНИДЕР ОСРЕЛ ОНБЮКЭМНЦН MAC РН БЯЕ ГЮАСДСР Н ГЮЫХРЕ Х ЮОЮВХ АСДСР КНЛЮРЯЪ ЙЮПЛЮММШЛ ЙЮКЭЙСКЪРНПНЛ. гЮЫХРЮ ДНКФМЮ АШРЭ ЙНЛОКЕЙЯМНИ, ХМРЕЦПХПНБЮММНИ Х СДНАМНИ Х БЛЕМЪЕЛНИ Б ЙНМЖЕ ЙНМЖНБ. Linux caps АШК УНПНЬХЛ ЬЮЦНЛ Х ОНОШРЙНИ, МН СБШ МХЙНЛС НМ ХМРЕПЕЯЕМ МЕ АШК ХАН БЯЕ ОНАЕФЮКХ ХЦПЮРЯЪ Я SEL/RSBAC... Х ГЮАПНЯХКХ/ОЕПЕЯРЮКХ ПЮГБХБЮРЭ ХДЕЧ Х ДСЛЮЧ ЯЙНПН ОНАЕЦСР ЙЮЙ НЬОЮПЕМШЕ НАЮПРМН ЕЦН ЙПСРХРЭ Х ОПХБНДХРЭ Б ЯНГМЮМХЕ=D

anonymous
()
Ответ на: комментарий от anonymous

Сначала перестань писать из-под IE, спец.

Во-вторых, попробуй позапускать эксплоиты.

jackill ★★★★★
()

А скажите-ка, новеловский AppArmor -- это нечто похожее, верно? Где можно почитать сравнение?

fAX ★★
()

Интересно.

А на каком уровне тоже самое есть в gentoo или debian? Ставишь seLinux и потом руками пишишь правила для все и вся или что-то более умное?

Toster
()

Вот это показалось интересным:

> Коммерческая поддержка этой политики доступна в RHEL5 со специальной лицензией и только для серверных систем с ограниченным числом установленных пакетов и без X Window System. Именно системы с данной политикой теперь имеют сертификацию EAL4+/LSPP.

То есть на сервере даже нельзя поставить пакет с икс-сервером для vnc или там Xvfb для прог, которым это может быть нужно? Или они в принципе запрещают ставить Xlib и проги, его использующие (попахивает маразмом). Или же все-таки всего лишь запрещено запускать локальный X-сервер с доступом к железу? Но политика в любом случае интересная, есть иксы => сервер потенциально небезопасен. Идея мне нравится.

anonymous
()
Ответ на: комментарий от anonymous

Никто ничего не запрещает. просто эта конфигурация не поддерживается. Т.е. саппорт вам скажет "пока не будет так-то и так-то решайте сои проблемы сами и читайте SLA" Как и Oracle на FreeBSD, хотя никто поставить не мешает - и судя по инету даже ставят :) И в 99,99% вам ни strict policy, ни MLS policy не понадобится.

anonymous
()
Ответ на: комментарий от anonymous

> И в 99,99% вам ни strict policy, ни MLS policy не понадобится.

Да у меня чисто академический интерес, лично мне targeted в centos хватает за глаза ;) Просто непонятно совершенно, _какая_ именно конфигурация не поддерживается. Какие-то пакеты стоять не имеют права (какие именно?) или что еще. Можно про это в деталях узнать? Понятно, что десктопные приложения содержат больше всего уязвимостей, и http://www.redhatmagazine.com/2007/04/18/risk-report-two-years-of-red-hat-ent... это очень хорошо демонстрирует. Но неужели запрещают вообще держать пакеты с иксовыми приложениями, даже для удаленного запуска если хочется иметь поддержку в этом "самом защищенном" варианте?

anonymous
()
Ответ на: комментарий от fAX

>А скажите-ка, новеловский AppArmor -- это нечто похожее, верно? Где можно почитать сравнение?

не совсем похожее :-) насколько я понял,в аппармор можно ограничить процесс с определенными именем. этого, видимо, может быть достаточно чтобы защититься от того, что некто получит рута, проломив, например, bind.

selinux дает возможность сделать и это и больше. но уж очень сложно его полиси пишутся, я не осилил и со вчера пытаюсь разобраться с apparmor.

anonymous
()
Ответ на: комментарий от Toster

> А на каком уровне тоже самое есть в gentoo или debian? Ставишь seLinux и потом руками пишишь правила для все и вся или что-то более умное?

Переключаешься на профиль с selinux и собираешь мир. Шаблоны правил в портаже есть. Редакторы правил тоже.

Lumi ★★★★★
()
Ответ на: комментарий от anonymous

> нЦН, МЮ РН НР МЕЦН Х РЮЙ Х КЕГСР ДШПЙХ ЙЮЙ БЬХ Х АКНУХ.

Что, бнопня, локаль в винде слетела из-за глюков? :)

> Ого, на то от него и так и лезут дырки как вши и блохи.

Например?

> MAC сам по себе кааастыль, не удивлюсь если линукс пойдет путем повального MAC то все забудут о защите и апачи будут ломатся карманным калькулятором.

Помимо SELinux, в Linux 2.6.12+ есть ASLR kernel.randomize_va_space=1 и механизм противодействия эксплуатации переполнений на хипе у glibc "из коробки", поэтому апачи ломаться калькуляторами в любом случае не будут. Покажи хоть один реально работающий на linux 2.6.12+ и glibc 2.3.4+ эксплоит, способный удаленно эксплуатировать переполнение буфера на стеке или куче в любом самом наидырявейшем демоне.

> Даже те приславутые алгоритмы в венде кои обходят как слепых кротов по сравнению с ним просто вершина вменяемости и безопастности.

Какие это "алгоритмы в венде"? Откуда это в винде MAC? Или речь про DEP, который ни разу не явлется MAC-ом и который убог настолько из-за отсутствия ASLR и возможности программно шеллкодом отключать NX, что на него даже есть реальные надежно работающие эксплоиты, позволяющие удаленно получить полный неограниченный шелл с правами системы(например, DNS-RPC)?

> SEL самая неудачная и мозгомертвая реализация MAC которая когда либо была видена миром. Как и MAC в целом.

И в чем же заключаются серьезные недостатки? Аргументы в студию, а не пустые слова.

> Защита должна быть комплексной, интегрированной и удобной и вменяемой в конце концов.

С тремя кнопками: "включить безопасность", "включить крутую безопасность" и "выключить безопасность"?

> MAC сам по себе кааастыль

Чем предлагаешь заменить MAC? Решением сделать аудит и переписать весь имеющийся софт с учетом правил написания безопасного кода и в дальнейшем принудить каждого разработчика следовать им?

sysenter
()
Ответ на: комментарий от Virun

> Это какие такие проблемы у него были _раньше_?

А как ты собрался защищаться от инсайдеров без мандатного контроля доступа?

DubHead
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.