В строке этого вопрос на StackOverflow и совершенно другой толпе, которая у нас есть, мне интересно: каковы ваши причины отключить SELinux (при условии, что большинство людей все еще это делают)? Хотели бы вы оставить его включенным? Какие аномалии вы испытали, оставив включенным SELinux? Какие другие поставщики, кроме Oracle, создают проблемы с поддержкой систем с включенным SELinux?
Дополнительный вопрос: кому-нибудь удалось запустить Oracle на RHEL5 с SELinux в принудительном целевом режиме? Я имею в виду, что strict было бы круто, но я не знаю, что это возможно даже отдаленно, так что давайте сначала остановимся на таргетинге ;-)
RedHat включает SELinux по умолчанию, потому что это безопаснее. Почти каждый поставщик, использующий продукты, производные от Redhat, включает SELinux выключен потому что они не хотят тратить время (и, следовательно, деньги), чтобы выяснить, почему это не работает. Люди Redhat / Fedora потратили огромное количество времени и усилий, чтобы сделать SELinux более жизнеспособным вариантом на предприятии, но не многие другие организации действительно заботятся о ваш безопасность. (Они заботятся о их безопасность и репутация безопасности их продукта, что совсем другое дело.)
Если вы можете заставить его работать, то дерзайте. Если вы не можете этого сделать, не ждите большой помощи от продавцов. Вероятно, вам помогут ребята из Redhat / Fedora, списки рассылки selinux и канал #selinux на freenode. Но от таких компаний, как Oracle - ну, SELinux не учитывает их бизнес-план.
Обычно лучше запускать SELinux в Permissive, чем полностью отключать его. Затем вы можете проверить (через audit2why) через некоторое время, чтобы увидеть, какие нарушения были бы запрещены при обычном использовании, и создайте собственные политики с помощью audit2allow если эти «нарушения» являются ложными срабатываниями для вашей установки.
Я обнаружил, что поведение SELinux в системах, не являющихся производными от Fedora, значительно более болезненно, чем то, что вы получаете с типичной системой Fedora / RHEL по умолчанию.
Если вы еще этого не видели, вы можете найти Руководство пользователя Fedora SELinux образовательные.
Причины для:
Причины против:
Тем не менее, если вы рассматриваете SELinux, я рекомендую книгу SELinux на примере.
Я работал на Компания с включенным SELinux в принудительном режиме в каждой системе. Ключевым моментом для нас было понимание и использование программы audit2allow, которую можно использовать для создания новых контекстных правил.
Сначала мы сгенерировали шаблон с помощью audit2allow, а затем использовали сценарий для его создания, например:
export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}
Скрипт setup_semodule:
#!/bin/sh
# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1
/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp
/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp
Это строит модуль из шаблона (файл .te), генерирует пакет, а затем загружает модуль.
Мы использовали Puppet для нашей системы управления конфигурацией, и мы написали конфигурацию для Puppet, чтобы управлять всем этим.
Модуль марионетки SELinux:
Причина, по которой его нужно отключить, заключается в том, что отладка может быть сложной задачей.
Однако сейчас мы не выключаем его. Мы почти всегда работаем. Иногда я выключаю его, чтобы быстро проверить, является ли SElinux проблемой или нет.
Теперь отлаживать намного проще, особенно если вы знакомы с audit2allow. Вам действительно не нужно понимать это с помощью audit2allow, но в некоторых случаях вы можете в конечном итоге раскрыть тонкости шире, чем вы думаете, с помощью audit2allow. Сказав, что некоторые SELinux лучше, чем ничего.
Я ни в коем случае не эксперт по SELinux и использую его всего пару лет. Я все еще не совсем понимаю основы, но я знаю достаточно, чтобы запускать приложения, включая те, которые включены в дистрибутив, и случайные вещи, скомпилированные из сети.
Главное, что мне пришлось использовать, это ls -lZ (показать контекст selinux), audit2allow, chcon, semodule, getenforce, setenforce и логические. С помощью этих инструментов мне удалось получить все приложения, которые мне нужно было запускать под SELinux.
Я считаю, что одна из самых больших проблем с отладкой проблем SELinux - это просто вспоминание проверки на наличие проблем SELinux, когда у меня возникают другие мудрые необъяснимые проблемы. Обычно мне нужно немного хитрости, чтобы сказать «ч! Проверьте SELinux !!».
Согласно справочной странице bind, SELinux намного безопаснее, чем запуск bind в chroot-тюрьме. Многие другие люди, которые знают гораздо больше, чем я, также рекомендуют его, поэтому сейчас я запускаю его вслепую. И подозреваю, что, несмотря на периодические проблемы, это, вероятно, стоит сделать.
Я отключил SELinux для AppArmor, Мне он показался более удобным и простым в обслуживании, чем SELinux.
Нет причин отключать его, если вы можете запустить его в разрешающем режиме. Это не будет мешать работающему приложению и по-прежнему будет обеспечивать полезный журнал безопасности. Единственное исключение касается пользовательских контекстов: если вы переключаетесь между разными пользователями, живущими внутри другого экземпляра Linux, работающего в chroot, у вас могут возникнуть проблемы.
SE Linux не так безнадежно недружелюбен, как раньше, по крайней мере, его нет в коммерчески поддерживаемых дистрибутивах, таких как RHEL5. По большей части вы можете оставить его включенным, и он подойдет ко всему, что предоставлено RedHat. Все остальное может быть переменным. Проблема в том, что профессиональные услуги по обеспечению работы приложений с включенным SE Linux - хороший источник дохода для таких компаний, как RedHat и Oracle, поэтому у них нет стимула делать все, чтобы все работало нормально ootb.