В списке рассылки OpenBSD-misc разгорелась дискуссия (http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Se...) в которой сравнивались текущие средства безопасности OpenBSD с возможностями предоставляемыми SELinux. Разработчики пришли к выводу, что главная проблема SELinux в излишне усложненном языке определения политик безопасности.
По опыту Damien Miller (http://www.mindrot.org/projects/), основного разработчика OpenSSH, для многих не типовых решений политики безопасности используемые в дистрибутивах по умолчанию непригодны, и большинство администраторов, вместо изменения правил доступа, прибегают к более простому пути - отключают SELinux.
Ted Unangst считает, что главная проблема организации безопасности, через определение политик, заключается в том, что политики всегда неправильны.
Darrin Chandler предполагает, что безопасность не должна даваться свыше, безопасность должна устанавливаться в процессе разработки. В OpenBSD безопасность - атрибут кода и часть процесса разработки.
SELinux systrace (http://www.citi.umich.edu/u/provos/systrace/)URL: http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Se...
Новость: http://www.opennet.me/opennews/art.shtml?num=12196
Не вполне понял мысль. Пытаются сказать что нужно делать безошибочный код?
очень похоже на то
только ведь ВСЕМ не ПРИКАЖЕШЬ писать правильный код :)
короче, придраться не к чему. вот и выдумывают: правила не те, пишу не так... :)
когда SELinux выпустят фронтенд к своим патчам с двумя чекбоксами "безопасно" и "сильно безопасно" - будут критиковать за излишнюю простоту
> выпустят фронтенд к своим патчам с двумя чекбоксами "безопасно" и "сильно безопасно"Давно уже есть где чекбоксы ставить - system-config-selinux
тока их там побольше двух :)
а "безопасно" и "сильно безопасно" выбирается в выпадающем списке :)
Соответственно "целевая политика" и "строгая"
> писать правильный код :) ...А как "правильный код" позволит задать правила редистрибуции документов?
Например, Маня может печатать и слать на мыло, группа Фени - просматривать, а группа Вени только печатать?И так далее?
Что-то там ум за разум у койкого.
Костылем это было костылем и останется, будем надеятся хватит ума не пихать эту хрень куда попало, чтобы потом не удалять
> В OpenBSD безопасность - атрибут кода и часть процесса разработки.одно другому не мешает.
Что и показывает подход SELinux:
надежные программы - отличноно ограничения со стороны ядра - лишь плюс к безопасности.
AppArmor, вроде легче, его ща пытаются протолкнуть на включение.
я хотел к gentoo прикрутить, так нигде ни слова про это :(. Оно тока в сусе и slackarmor. Да и что-то не особо мне понравилось. Лучше чем selinux(selinux с нуля конфигурить самоубийство), но есть принципиальные проблемы типа права к прогам привязаны к путям а не к лабелам. Имхо это скорее минус чем плюс.
> Лучше чем selinux(selinux с нуля конфигурить самоубийствоНикто с нуля selinux не конфигурит - есть Reference Policy (http://oss.tresys.com/projects/refpolicy) на которую перешли с 5-й Fedora.
в убунту apparmor будет
На стандартных ситуациях писать свои политики незачем. И так > 200 стандартных процессов описано и предусмотрена куча т.н. "переключателей". Запускаем system-config-selinux и вперед кастомизируем политику под конкретные нужды/нестандартную конфигурацию в графике. Да и тупейшему audit2allow можно за пару часов выучиться и свой модуль без глубокого знания конструкций написать. В любом случае жэто будет лучше чем отключать selinux.
Глупость , ни кто ни чем не занимается. Два подхода к безопасности, в заметке нечётко расставлены интонации. Идея в проблеме чрезмерного усложнения системы ,что ведёт к увеличению возможности ошибки администратора, и снижения оной путём более критичного отношения к безопасности при написании кода. Что в принципе правильно,как и призыв "нет войне" все понимают что да , войне таки нет, но войны все равно идут.
Одно другого не исключает: можно и программы стараться писать без ошибок и создавать новые технологии безопасности.Кстати, системы типа SELinux помогают предотвратить неописанные угрозы. Допустим некая программа написана без багов и реализует возможности некоего сетевого протокола на 100% в соответствии с неким RFC. И вот через годик обнаруживается дырка, но не в программе, а в протоколе!
Всё это так же и к FreeBSD-шному MAC-у относится, за 2 года руки так и не поднялись настроить, т.к. мегагемор... Надеюсь OpenBSDшники придумают что-то лучше, на что потом все перейдут... :-)
>Всё это так же и к FreeBSD-шному MAC-у относится, за 2 года
>руки так и не поднялись настроить, т.к. мегагемор... Надеюсь OpenBSDшники придумают
>что-то лучше, на что потом все перейдут... :-)Вероятность этого недалека от вероятности того что миллион мартышек за печатными машинками напишут войну и мир.Это немного не те люди которые могут спроектировать что-то простое для конечного юзера.
>Вероятность этого недалека от вероятности того что миллион мартышек за печатными машинками
>напишут войну и мир.Это немного не те люди которые могут спроектировать
>что-то простое для конечного юзера.Ну про совсем конечных пользователей речь и не идёт, нужно всё-таки быть администратором системы. А вот придумать эти ребята много чего придумали: pf, OpenSSH и т.д. И система одна из лучших по части документированности!