Каковы причины отключить SELinux (предполагая, что большинство людей все еще делают это)? Хотели бы вы сохранить его включенным? С какими аномалиями вы столкнулись, оставив SELinux включенным? Кроме Oracle, какие еще производители испытывают проблемы с поддержкой систем с включенным SELinux?
Бонусный вопрос: кому-нибудь удалось заставить Oracle работать на RHEL5 с SELinux в целевом режиме принуждения?
Ответ 1
RedHat включает SELinux по умолчанию, потому что это безопаснее. Почти все производители, использующие продукты на базе Redhat, выключают SELinux, потому что не хотят тратить время (и, следовательно, деньги) на выяснение причин неработоспособности. Люди из Redhat/Fedora приложили огромное количество времени и усилий, чтобы сделать SELinux более жизнеспособным вариантом для предприятий, но не так много других организаций действительно заботятся о вашей безопасности (они заботятся о своей безопасности и репутации своего продукта, а это совершенно разные вещи).
Если вы можете сделать так, чтобы это работало, то действуйте. Если нет, то не ждите большой помощи от поставщиков. Возможно, вы сможете получить помощь от ребят из Redhat/Fedora, из списков рассылки selinux и канала #selinux на freenode. Но от таких компаний, как Oracle, — SELinux не очень-то входит в их бизнес-план.
Ответ 2
Причины за:
Более высокий уровень безопасности за счет обязательного контроля доступа.
Причины против:
Сложно разобраться.
Сложно управлять.
Сложно устранять неполадки.
Если вы рассматриваете 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
# Где хранить файлы, связанные с selinux
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, чтобы управлять всем этим.
Ответ 3
Причина отключения в том, что это может стать проблемой при отладке.
Однако сейчас мы его не отключаем и почти всегда держим его запущенным. Я иногда выключаю его, чтобы быстро проверить, является ли SElinux проблемой или нет.
Сейчас отлаживать гораздо проще, особенно если вы хорошо знакомы с audit2allow. С audit2allow вам не нужно разбираться в этом, но иногда с audit2allow вы можете открыть более широкие возможности, чем вы думаете. Тем не менее наличие SELinux лучше, чем его отсутствие. Я ни в коем случае не являюсь экспертом по SELinux и использую его всего пару лет. Я все еще не понимаю основ, но я знаю достаточно, чтобы запустить приложения, причем как те, что входят в дистрибутив, так и случайные, скомпилированные из сети.
Основное, что мне приходилось использовать, — это ls -lZ (показать контекст selinux), audit2allow, chcon, semodule, getenforce, setenforce и booleans. С помощью этих инструментов мне удалось запустить все необходимые приложения под SELinux.
Для меня одна из главных сложностей с отладкой проблем SELinux — это просто вспомнить, что нужно проверить наличие проблем SELinux, когда у меня возникают другие необъяснимые проблемы. Согласно man-странице bind, SELinux намного безопаснее, чем запуск bind в chroot jail. Многие другие люди, у которых гораздо больше знаний, чем у меня, также рекомендуют его, так что теперь я запускаю его вслепую. И подозреваю, что, несмотря на возникающие иногда проблемы, это, вероятно, стоит сделать.
Ответ 4
SELinux не так безнадежно проблемен, как раньше, по крайней мере, его нет в коммерчески поддерживаемых дистрибутивах, таких как RHEL5. По большей части вы можете оставить его включенным, и он будет хорошо работать со всем, что поставляется в RedHat. Со всем остальным может быть по-разному. Проблема в том, что работа по предоставлению профессиональных услуг для обеспечения работы приложений с включенным SELinux является хорошим источником дохода для таких компаний, как RedHat и Oracle, поэтому у них нет стимула заставлять все хорошо работать в ootb.
Linux