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 ()

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

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

Ее бы в RHEL наверняка нашли, так что практически исключено.

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

всё равно как то неприятно от мысли что софт с "архитектурой безопасности" разработанной "IT разведкой" одной страны - лицензируется для государственного использования в другой стране...

zort
()

Ну, это, вообще-то, разные подходы, в плане систем обеспечения безопасности.. И простые сравнения тут некорректны.. Сравнение подходов тоже безсмысленно.. Да, SELinux достаточно сложен в настройках, но, свои функции он выполняет..

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

> Да не так там все сложно. Достаточно внимательно прочесть доку на http://fedoraproject.org/wiki/SELinux (хотя там немало информации) и "пощупать" на практике утилитами, как это работает. А потом несколько дней следить за аудитами и реагировать на них (вначале чуть подумав, потом уже на автомате). Через пару неделек все пойдет отлично.

Да это всем понятно, вот только стоит перенастроить какой-нибудь демон на сервере, а то и обновить и сервер встал... Такая безопасТность никому не нужна, если только админу желающему уволиться по-плохому.

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

Перенастраивать на работающей системе не стоит, конечно. Selinux относится к тем технологиям, которые нужно включать или на новых системах, или при спокойно перенастройке.

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

selinux сам по себе процессы не трогает и не убивает, просто соответсвующая операция - ну там open, read, write, exec и т.д. им не удается, возвращается с ошибкой "нет прав" или подобной. Обычно на это реагируют мягко, но не все.

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

> Да это всем понятно, вот только стоит перенастроить какой-нибудь демон на сервере, а то и обновить и сервер встал...

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

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

>>Да это всем понятно, вот только стоит перенастроить какой-нибудь демон на сервере, а то и обновить и сервер встал... Такая безопасТность никому не нужна, если только админу желающему уволиться по-плохому.

админу, который на production машине начнёт что-то обновлять без предварительной проверки результатов на тестовой следует точно уволиться

>>PaX, GRSec, RSBAC опять же только patches. База на которой они все основаны не внесена в vanilla kernel.

ну да, люди развивают проекты, работают, регулярно делают релизы - но это 'просто patches', фигня. Что до vanilla kernel - его кто-то использует ? А SELinux - тоже просто патч? А в OpenBSD gcc типа не патч?

вот опять - начинают сравнивать дистрибутив и vanilla kernel. Ну не бред?

deadman ★★
()

Гм. Trusted Solaris - рулит всех. :-)

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

> Где можно прочитать про шарахания от ZIP?

Как следствие шаразания от LZW. ZIP archive files [старых версий] using LZW-based shrink compression.

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

> Как следствие шаразания от LZW. ZIP archive files [старых версий] using LZW-based shrink compression.

Да ладно, lzw вроде же только в первой версии был, которая хз сколько лет не применяется.. pkzip/pkunzip 2.0 по-моему еще в 93 или 94 году вышли, и там на deflate перешли (и добились лучшего сжатия). Помню, много жалоб тогда было о несовместимости - он не умел создавать архивы, которые можно раскрывать первой версией, и разные сторонние проги тогда только про нее и знали, сам же pkzip 2.0 долго был весьма бажным продуктом - под 3-ей виндой плохо работал и т.д., люди вынуждены были сидеть на первом.

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

>> Как следствие шаразания от LZW. ZIP archive files [старых версий] using LZW-based shrink compression.

> Да ладно, lzw вроде же только в первой версии был,

Ведь я указал - старых версий (а версий по сути всего две и есть, первая - старая :) Я разве писал, что он сейчас от zip шарахается? Если да - то я виноват.

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

> админу, который на production машине начнёт что-то обновлять без предварительной проверки результатов на тестовой следует точно уволиться

Я боюсь, что только такой путь вы и видите: админ тестит все обновления тщательно и досконально на тестовой машине...

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

> Ведь я указал - старых версий (а версий по сути всего две и есть, первая - старая :) Я разве писал, что он сейчас от zip шарахается? Если да - то я виноват.

Да я что, я ничего.. Просто вспомнил, что pkzip 1.0 это было ТАК давно, что про это можно и не вспоминать сейчас.

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

>btw, бинарники в obsd default install имеют stack-protection by default (ProPolice).

>[cryptus]$ strings /usr/bin/ident |grep stack __stack_smash_handler

меня всегда заставляет улыбаться аргумент "default install", в production default install _не ставится_. и мне stack-smash-protection на десктопе нафиг несдался.

[~] % strings /usr/bin/ls |grep smash
__stack_smash_handler

[~] % uname -srm
Linux 2.6.20-hardened-r10 i686

[~] % gcc -v
gcc version 3.4.6 (Gentoo Hardened 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)

и?

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

> Linux devs puts a patch-set вместо того что-бы вклучить эти вещи в vanilla kernel.

ЛПиП. SELinux и механизм capabilities штатно входят в состав "vanilla kernel"

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

> PaX, GRSec, RSBAC опять же только patches. База на которой они все основаны не внесена в vanilla kernel.

А вот здесь я несколько сомневаюсь. Как раз контроль доступа к стандартным файловым операциям сделан расширяемым - в ядро можно подключать свои security hooks, которые будут контролировать что нужно и как нужно. И если по уму, то в действительности эти патчи нужны чтобы ограничить "видимость" во всяких sysfs/procfs.

no-dashi ★★★★★
()

Похоже, автор статьи действительно не смог осилить SELinux.

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

> вот только стоит перенастроить какой-нибудь демон на сервере, а то и обновить и сервер встал...

Примеры в студию. При обновлении демонов они встают в теже места с теми же настройками (и настройки кстати достаточно грамотные).

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

> Я боюсь, что только такой путь вы и видите: админ тестит все обновления тщательно и досконально на тестовой машине...

Узнаю "специалиста" :-) При эксплуатации промышленных систем тестирова делается обязательно, и еще бэкап перед обновлением. И этот порядок не подлежит обсуждению, в принципе.

no-dashi ★★★★★
()

Люди правы, я тоже обычно совсем отключаю Selinux, как только она начинает мешать. Уж очень геморно с ней разбираться, особенно когда сервера в локальной сети. А если смотрят в инет -- то тут лучше 1 задача -- 1 сервер, а всё остально просто удаляется, ну и + iptables.

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

> birdie, что делаешь во второй половине случаев, когда не отрубаешь?

во второй половине случаев -- selinux еще не мешает

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

> и?

Да чего и-то? Сравнили авторы жопу с пальцем и флуда развели. Защита стека и МАС вообще слабо пересекающиеся вещи, имеющие разные задачи.

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

> Примеры в студию. При обновлении демонов они встают в теже места с теми же настройками (и настройки кстати достаточно грамотные).

Да вот вам простой: добавили директорию в Apache и LAMP встал. В журнале ничего про попытки несанкционированного доступа, в итоге выключили SELinux и всё заработало.

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

> А если смотрят в инет...

Сходи в толксы, почитай как люди флеш-плееры скачивают :) Если будет стоять настроенный SELinux, фиг кто такое сделает.

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

>> Я боюсь, что только такой путь вы и видите: админ тестит все обновления тщательно и досконально на тестовой машине...

> Узнаю "специалиста" :-) При эксплуатации промышленных систем тестирова делается обязательно, и еще бэкап перед обновлением. И этот порядок не подлежит обсуждению, в принципе.

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

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

бэкап удел трусов, и это не обсуждается.

anonymous
()

Полнейший бред. Это совершенно разные вещи.

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

> Потому, что LSM что?

"Потому, что LSM наме не нравится - его изобрели не мы, он позволяет другим модулям принимать решения вместе с нашими, и еще он нам не нравится" :-)

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

Где гарантия, что ошибки не вылетят потом? SELinux и продакшн-системы вещи слабо совместимые, в отличии OpenBSD В OpenBSD очень сложно убить систему безопасности В Linux её ещё сложнее настроить И надо признать, что SELinux избыточен.

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

> "Потому, что LSM наме не нравится - его изобрели не мы, он позволяет другим модулям принимать решения вместе с нашими, и еще он нам не нравится" :-)

Ты точно ходил по ссылкам ?

Там английским по экрану сказано что LSM не предоставляет необходимой функциональности для реализации поверх него что GRSec что RSBAC и один хрен приходиться патчить ядро.

Ну и кому такое понравится ?

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

ну так это не официальное все. наложил патч и все. в obsd мне ничего накладывать не надо - все уже есть.

а то что на desktop тебе это и не надо, так ты просто не понял вообще что это. ты просто тупо наложил патч, либо слил готовое, не подтрудившись углубиться в тему.

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

>> Потому, что LSM что?

>"Потому, что LSM наме не нравится - его изобрели не мы, он позволяет другим модулям принимать решения вместе с нашими, и еще он нам не нравится" :-)

Не смешно и не правда, "Не нравится" основоном потому, что мало возможностей.

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

> SELinux и продакшн-системы вещи слабо совместимые

Что за бред? Такое сказать может только тот, кто ничего не знает про selinux. Он прекрасно совмещается с чем угодно - отличие только в том, что требует нескольких дополнительных разрешений для некоторых конкретных серверов. Что легко выясняется на этапе установки/настройки - и все.

А защита стэка в линуксе и так есть, средствами gcc+glibc+опций при компиляции. Для C'шных программ. Весь софт в федоре и rhel уже давно так защищен. Более того, с 8 федоры новая версия glibc (2.6.90, т.е. с 2.7 это будет везде) и последний gcc позволяют включить такую же защиту для c++ программ. И 8 федора уже собирается с ней - rhel 6 тоже будет ее включать. В свое время включение защиты для C помогло найти много бажного кода, думаю, защита для c++ найдет не меньше.

Но работает она совсем иначе, чем selinux - там программа при попытке сделать что-то неподобающее со стэком немедленно убивается.

anonymous
()

А вот и новое доказательство того что Linux desv do NOT understand Security as a process:

Linux Kernel 2.4/2.6 x86-64 System Call Emulation Exploit

/* * exploit for x86_64 linux kernel ia32syscall emulation * bug, discovered by Wojciech Purczynski <cliph_at_isec.pl> * * by * Robert Swiecki <robert_at_swiecki.net> * Przemyslaw Frasunek <venglin_at_freebsd.lublin.pl> * Pawel Pisarczyk <pawel_at_immos.com.pl> * of ATM-Lab http://www.atm-lab.pl */

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

$ strings /bin/ls |grep stack_chk __stack_chk_fail

$ gcc -v Используются внутренние спецификации. Целевая архитектура: x86_64-redhat-linux Параметры конфигурации: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Модель многопотоковости: posix gcc версия 4.1.2 20070502 (Red Hat 4.1.2-12)

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)

Современные машины достаточно мощные, чтобы пожертвовать крохой производительности даже на десктопе ради подобных защит.

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

> А вот и новое доказательство того что Linux desv do NOT understand Security as a process:

Кстати, ни один эксплоит ядра/glibc за последние годы не работал на rhel с включенным selinux. Там не нужно было судорожно обновлять продакшн-систему после нахождения очередного злобного бага.

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

> "Потому, что LSM наме не нравится - его изобрели не мы, он позволяет другим модулям принимать решения вместе с нашими, и еще он нам не нравится" :-)

Так написал бы сразу по нашему -- "сосёт" ;)

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

> Не смешно и не правда

Да ну? Вот первая из "причин" взятых от автора grsecurity: It seems as though LSM has been designed for the few systems that support it currently

А вот еще одно утверждение - уже от RSBack: With the stacking system, each registered decision module holds all others along the chain in its mercy. I am not willing to accept such a dependency on other modules.

И где я не прав? Только в том что не упомянул заявление "мы хотим реализовать не только контроль доступа, который реализует LSM, но и чего-то еще для чего хуков не предусмотрено"? Так я это говорил в самом начале, когда упомянул что grsecurity/rsback влезают еще и в другие куски кода, не только в те что покрыты LSM.

no-dashi ★★★★★
()

И вот еще - я прямо сейчас пишу это сообщение с системы со включенным selinux и настройками "по умолчанию". И представьте себе - все работает...

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

А как в SeLinux на CentOS5 посмотреть текущие правила политики в читабельном виде? Так и не понял как это сделать.

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

> И где я не прав? Только в том что не упомянул заявление "мы хотим реализовать не только контроль доступа, который реализует LSM, но и чего-то еще для чего хуков не предусмотрено"?

Не только в этом, но и в этом тоже.

> Так я это говорил в самом начале, когда упомянул что grsecurity/rsback влезают еще и в другие куски кода, не только в те что покрыты LSM

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

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

> Первой причиной в твоем списке шла "его изобрели не мы"

"И если по уму, то в действительности эти патчи нужны чтобы ограничить "видимость" во всяких sysfs/procfs." (c) no-dashi ***** (Score: 682 MaxScore: 682) (*) (27.09.2007 6:44:36)

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

> А как в SeLinux на CentOS5 посмотреть текущие правила политики в читабельном виде? Так и не понял как это сделать.

Поставить пакет selinux-policy-targeted-sources и в /etc/selinux/targeted/src/policy читать .te файлы.

Хотя не очень представляю, зачем это нужно. Править их точно не нужно, нужно результат аудита пропускать через audit2allow и получать новые строчки для персонального .te-файла с локальной политикой, а потом добавлять новый вариант локальной политики в selinux. По умолчанию локальная политика пуста. Все изменения и настройки, которые могут потребоваться в selinux - либо разрешения, добавляемые к локальной политики (можно и запрещения, конечно же, но это для совсем матерых профессионалов по безопасности - я исхожу из другой проблемы, как сделать, чтобы selinux не запрещал ничего из того, что нужно), либо переключением разрешений (getsebool/setsebool). Это такие опции для некоторых гибко созданных политик, когда можно изменять поведение без изменения политик. Главное не переусердствовать, потому что среди них есть достаточно глобальные.

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

>Поставить пакет selinux-policy-targeted-sources и в /etc/selinux/targeted/src/policy читать .te файлы.

Нашел такой пакет только для 4-и. А нужно для четкого понимания как и что работает. Слепое использование audit2allow чревато слишком мягкими разрешениями.

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

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

yumdownloader --source selinux-policy

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

так и используйте audit2allow для получения .te, а не .рр, .te правьте ручками как нужно.

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