Причины отключить / включить SELinux

В связи с этим вопросом о StackOverflow и совершенно другой толпе, которая у нас здесь, я задаюсь вопросом: каковы ваши причины отключить SELinux (если большинство людей все еще делают это)? Вы хотите оставить его включенным? Какие аномалии вы испытали, оставив SELinux включенным? Кроме Oracle, какие другие поставщики создают проблемы с поддержкой систем с включенным SELinux?

Дополнительный вопрос: кому-нибудь удалось запустить Oracle на RHEL5 с SELinux в принудительном целевом режиме? Я имею в виду, строгий был бы офигенным, но я не думаю, что это возможно даже отдаленно, поэтому давайте сначала остановимся на таргетах ;-)

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 by Example .

Я работал в компании, которая включила 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:

• http://github.com/sansnoc/puppet/tree/master/selinux

Причина, по которой он отключен, заключается в том, что отладка может быть болезненной.

Однако мы не выключаем его сейчас. Мы почти всегда поддерживаем это. Я иногда отключаю его, чтобы быстро проверить, является ли SElinux проблемой или нет.

Теперь гораздо проще отлаживать, особенно если вы хорошо знакомы с Audit2allow. На самом деле вам не нужно разбираться в этом с Audit2allow, но вы можете в конечном итоге открыть тоньше шире, чем вы думаете с Audit2allow. Сказав, что некоторые SELinux лучше, чем ничего.

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

Главное , я должен был использовать , являются ls -lZ(контекст SELinux шоу), audit2allow, chcon, semodule, getenforce, setenforceи булевы. С помощью этих инструментов мне удалось получить все необходимые приложения для работы под SELinux.

Я нахожу одну из больших проблем с отладкой проблем SELinux, просто не забываю проверять наличие проблем SELinux, когда у меня возникают другие мудрые необъяснимые проблемы. Обычно мне требуется немного смелости, чтобы сказать «ч! Проверь SELinux !!».

Согласно справочной странице bind, SELinux гораздо безопаснее, чем запускать связывание в изолированной тюрьме. Многие другие люди, которые имеют гораздо больше подсказок, чем я, также рекомендую это, поэтому я запускаю это вслепую сейчас. И подозреваю, что, несмотря на случайные проблемы, это, вероятно, стоит сделать.

Я отключил SELinux для AppArmor , он мне показался намного удобнее и проще в обслуживании, чем SELinux.

Нет причин отключать его, если вы можете запустить его в разрешающем режиме. Это не будет мешать работающему приложению, и все равно обеспечит полезное ведение журнала безопасности. Единственное исключение касается пользовательских контекстов: если вы переключаетесь между разными пользователями, живущими в другом экземпляре Linux, работающем в chroot, у вас могут возникнуть проблемы.

SE Linux не так безнадежно недружелюбен, как раньше, по крайней мере, в коммерческих дистрибутивах, таких как RHEL5, нет. По большей части вы можете оставить его включенным, и все будет в порядке со всем, что предоставлено RedHat. С чем-либо еще это может быть переменным. Проблема в том, что профессиональная работа по обслуживанию приложений, работающих с SE Linux, является хорошим источником дохода для таких компаний, как RedHat и Oracle, поэтому у них нет стимула заставить все работать хорошо.