LINUX.ORG.RU

SeLinux в сравнении с безопасностью OpenBSD


0

0

Недавно в списке рассылки OpenBSD-misc состоялась дискуссия на предмет сравнения безопасности ядра Линукса 2.6.x в виде подсистемы SeLinux с тем, что предлагается в OpenBSD. Общее мнение таково: политика безопасности SeLinux и язык, на котором она пишется, слишком сложна, что приводит к тому, что, цитата Damien Miller: "при развёртывании всех известных мне средних и крупных инсталляций Линукса, SeLinux был отключен. Как только вы делаете шаг в сторону от конфигурации по умолчанию, то предлагаемые политики, с которыми поставляется ваш дистрибутив, больше не работают, и затем всё просто ломается". Другой участник дискуссии просуммировал высказанное следующим образом: "проблема безопасности, которая опирается на какую-либо [предопределенную] политику, в том, что последняя всегда неверна".

Далее была высказана следующая [как мне кажется очень правильная] мысль: "Нельзя прививать безопасность - её нужно интегрировать в основной процесс разработки. Я уверен, что мэйнтейнеры накладывают все возможные патчи, но это не исправляет фундаментальный изъян этого процесса. Это не ошибка в их работе - это неотъемлемая часть ситуации. Но это всё равно изъян."

"Проблема с SeLinux в том, что это просто кнопка, которую можно нажать, оставив систему без сверхнадёжной защиты". OpenBSD имеет более универсальну систему защиты в виде propolice stack protection, random library mappings, proactive privilege separation, W ^X и systrace.

>>> Подробности

★★★★★

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

из опыта сборки selinux-а под гентой скужу вот вам если уто не пробовал. Вещь шикарная, ставить ее на этот дистр-можно застрелиться Работает супер (под рутом никто ничего сделать не мог) Но поставляемые файла политик для различных пакетов (а они отличаются от шапочных по синтаксису-и не подходят)-настолько корявые, что пришлось отказаться от этого режима) Никогда не знаешь-это у тебя служба глючит или файл политик. Дорабатывать напильником конечно же не стал. Особенно это касается сетевых сервисов.. Немного подожду, пока окрепнет эта тема и вернусь на нее, а пока рано. Не генерить же X -ы на сервере под шапкой, а потом оттуда файл политик...

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

> Нашел такой пакет только для 4-и.

А. Хм. Ну да.

В таком же виде не получить, потому что работа политик начиная с fc6/rh5 изменилась. Теперь есть общее описание, а из него по условиям генерятся конкретные политики - и targeted, и strict.

Находятся исходники в пакете selinux-policy-devel. Думаю, из них можно получить .te-файлы для конкретных услових одним из инструментов, идущих в том же пакете. Там есть примеры, но док нет. Считается, что пользователям сюда лезть незачем, а те, кто лезет, и так знают, что делают.

> А нужно для четкого понимания как и что работает

Для некоторых сложных демонов про запрещения и управления ими можно почитать в мане, apropos selinux тут поможет. На страницы "apropos selinux |grep _" стоить глянуть, в частности.

> Слепое использование audit2allow чревато слишком мягкими разрешениями.

Почему же? По сообщению аудита четко видно, что за прога и что она пытается сделать. setroubleshoot поможет получить "человеческое" объяснение этому, если так неясно (падает правда иногда на попытке объяснить, собака ;)). audit2allow создает "минимально допустимое" правило разрешения - обычно его, кстати, оказывается недостаточно, нужно несколько раз повторить - ну там разрешить и open, и read, и getattr..

Разрешать вообще все, что предлагает audit2allow нет смысла, тем более что аудит генерится не только из-за ограничений selinux, иногда это обычные юниксовые права и ограничения, и смысла в "разрешении" selinux'у чего-либо, что все равно будет запрещено, нет. Поэтому нужно подумать немного, стоит ли это разрешать - но исходная политика тут особо не помогает, только здравый смысл...

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

>а хоть кому-то удалось сделать безопасную ось и что это такое?

Это ос удовлетворяющая определенным классам безопасности из т.н. "Оранжевой книги".

Я не уверен, но возможно это VMS и Trusted Solaris.

Sun-ch
()
Ответ на: комментарий от saper

> Админ != профессиональный тестер, я думаю вы это понимаете. И тратить свое время на отладку SELinux, чтение ChangeLog обновляемого пакета он зачастую не может.

1. тестер гоняет беты, а админ должен знать что он ставит

2. тестеры этим занимаются постоянно, а админ раз попробовал, у себя настроил -- по шаблону на серверах поставил.

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

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

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

> реально нужна прослойка между селинуксом и админом

Да до фига там прослоек и для анализа аудита, и для управления переменными, и для управления политиками. Для первых двух задач даже гуевые есть! setroubleshoot-gui, system-config-selinux.

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

>>а хоть кому-то удалось сделать безопасную ось и что это такое?

>Это ос удовлетворяющая определенным классам безопасности из т.н. "Оранжевой книги".

"Определенным" или конкретно B*? А то и Линукс, и Windows2000 сертифицированы по C2.

> Я не уверен, но возможно это VMS и Trusted Solaris.

Я тоже не уверен, но ОС, сертифицированных по B1 и выще, не существует.

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

> Я тоже не уверен, но ОС, сертифицированных по B1 и выще, не существует.

Да ладно. http://www.i2r.ru/static/287/out_14377.shtml

А еще RHEL 5 в одном из специализированных защищенных вариантов претендовал на B1, насколько я помню (получить-то вряд ли еще успел).

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

>> Я тоже не уверен, но ОС, сертифицированных по B1 и выще, не существует.

> Да ладно. http://www.i2r.ru/static/287/out_14377.shtml

Спасибо за ссылку, анонимный брат. Мои данные явно устарели :) Правда, в этой статье ссылки на сертификацию NT4 у меня не открываются.

Прикольно, что на B2 был сертифицирован только древний Xenix o_O всё остальное - B1 и ниже.

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

> А на сервере Fedora или RHEL/CENTOS?

У меня ни то и не другое, последняя жалоба была от админа CentOS.

saper ★★★★★
()
Ответ на: комментарий от no-dashi

>> Админ != профессиональный тестер

> Вы хоть раз в жизни сложнее LAMP что-нибудь обновляли?

Я ни разу в жизни не только не обновлял, но и не настраивал LAMP. Все что я пишу основано на жалобах знакомых администраторов, и если бы это было один раз и только от начинающих, то я бы не вступал в эту дискуссию.

В OpenBSD пути назад нет, поэтому там тестированием занимаются разработчики, и для них тоже пути назад нет, в отличие от Linux где есть большая зеленая кнопка, нажав на которую, можно отключить систему безопасности именуемую SELinux. Вы понимаете разницу в подходах между mainstream и additional feature? В OpenBSD подсистема безопасности - mainstream, в RH-based Linux подсистема SELinux - additional feature.

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

> 100% софта в федоре, rhel и centos собирается с -D_FORTIFY_SOURCE=2 для различных защит от переполнения буферов (http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html) и с -fstack-protector для защиты стэка (http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01193.html).

Fedora, RHEL, CentOS, Hardened Gentoo и всё? Это должно быть в каждом Linux и для любого приложения, чтобы говорить о широкой и хорошей протестированной поддержке. Но увы, это не так. Валить тестирование таких вещей на админа - не всегда оправдано.

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

> Я тоже не уверен, но ОС, сертифицированных по B1 и выще, не существует.

Операционная система Gemini, единственная и последняя сертифицированная по уровню A1.

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

> 1. тестер гоняет беты, а админ должен знать что он ставит

Из вашего текста не понятно, что делать с SELinux :-) Ну вот выпустили новую версию samba, ее потестили (раз она оказалась в репозитории с обновлениями).

Админ знает, что он ставит обновление Samba из официального репозитория, но почему то новая версия не работает, а стабильно падает на второй минуте после запуска. И вариантов остается уже 2: или админ копает ChangeLog, а то и diff исходников делает, или выключает SELinux. Как вы думаете, что выберет большинство начинающих админов? ;-)

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

> OpenBSD - дистрибутив, Linux - всего лишь ядро. Как можно > сравнивать целый дистрибутив с ядром системы? ну как-как? тут же любят сравнивать Windows с ядром линукс:)) так отчего бы не сделать наоборот с OpenBSD и линукс?

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

>По ссылке (ЛОРовец?): September 25, 2007 - 7:18pm PiotrowskiM
>LOL, OBSD trolls talk about SELinux...

Нет, это директор Эрмитажа Михаил Пиотровский

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

Я работаю на одну Канадскую компанию, у нас своя OS построенная на базе FreeBSD 4.10 - SCORE. Отдельно не продается. Дык EAL4+ :)

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

>Я работаю на одну Канадскую компанию, у нас своя OS построенная на базе FreeBSD 4.10 - SCORE. Отдельно не продается. Дык EAL4+ :)

Эт те что по офисам ходят, хрень вскую продают?

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

> Все что я пишу основано на жалобах знакомых администраторов, и если бы это было один раз и только от начинающих, то я бы не вступал в эту дискуссию

Я видел много "хороших и опытных администраторов", которые не смогли осилить bind в chroot, а простейшая задача "посадить apache с php в chroot" вгоняла их в ступор на две недели.

no-dashi ★★★★★
()
Ответ на: комментарий от saper

> или админ копает ChangeLog, а то и diff исходников делает

Или получает по рогам за то что не оттестировал, либо откатывается на предыдущую версию и пишет багрепорт в поддержку. Ах да - решение проблем в поддержке - за деньги. Зовется Redhat или Novell.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>> или админ копает ChangeLog, а то и diff исходников делает

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

У меня как то не вяжется "админ копает ChangeLog, а то и diff исходников делает" с понятиями production, stable, mainstream.

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

>>Я работаю на одну Канадскую компанию, у нас своя OS построенная на базе FreeBSD 4.10 - SCORE. Отдельно не продается. Дык EAL4+ :)

>Эт те что по офисам ходят, хрень вскую продают?

Не понял :)
Я к тому что мы продаем продукты у которых внутре неонка с EAL4+. Отдельно ея купить нельзя. А ты о чем?

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

> У меня как то не вяжется "админ копает ChangeLog, а то и diff исходников делает" с понятиями production, stable, mainstream.

Только видишь ли, с понятиями production и т.д. у тебя не вяжется не что иное, как гипотетическая ситуация, которую ты описал в одном из предыдущих писем:

> Админ знает, что он ставит обновление Samba из официального репозитория, но почему то новая версия не работает, а стабильно падает на второй минуте после запуска.

Ну да, не похоже на stable и т.д. Наверное это был бы вовсе и не stable...

Есть множество вещей, которые теоретически могут нарушить работу системы при обновлении - другие права доступа, изменения в настройках фаерволла, в API и т.д. Но кому придёт в голову утверждать, что правам доступа, фаерволлу и API не место в ответственных случаях? :-) То же самое и с SeLinux. Нужно просто правильно пользоваться. В тех дистрибутивах, где наиболее важной характеристикой считается стабильность, предпочитают при обновлении вносить в систему минимальные изменения (к примеру, не переходить в стабильной ветке на новую версию программы, а исправить ошибку в той, что используется). Что мешает аналогично поступать с SeLinux - не менять настройки без необходимости (которая вряд ли возникнет, если версии и настройки программ остаются прежними)?

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