Причини відключення / включення SELinux

У рядку цього питання щодо StackOverflow та зовсім іншого натовпу, який ми маємо тут, мені цікаво: які ваші причини для відключення SELinux (якщо припустити, що більшість людей все ще роблять)? Ви хочете, щоб це було включеним? Які аномалії ви відчули, залишивши SELinux увімкненим? Окрім Oracle, які інші постачальники створюють проблеми із підтримкою систем із підтримкою SELinux?

Питання про бонус: комусь вдалося змусити Oracle працювати на RHEL5 разом із SELinux при застосуванні цільового режиму? Я маю на увазі, суворий був би приголомшливим, але я не думаю, що це можливо навіть віддалено, тому давайте спочатку залишимося з цільовим ;-)

RedHat за замовчуванням вмикає SELinux, оскільки це безпечніше. Майже кожен постачальник, який використовує продукти, отримані Redhat, відключає SELinux , оскільки їм не потрібно вкладати час (а отже й гроші), щоб зрозуміти, чому річ не працює. Люди Redhat / Fedora вклали величезну кількість часу та зусиль, зробивши SELinux більш життєздатним варіантом у Enterprise, але не багато інших організацій дійсно піклуються про вашу безпеку. (Вони дбають про свою безпеку та безпеку репутації свого продукту, що зовсім інша річ.)

Якщо ти зможеш змусити його працювати, то йди за цим. Якщо ви не можете, тоді не чекайте великої допомоги від постачальників там. Напевно, ви можете отримати допомогу від 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:

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

Причина її вимкнення полягає в тому, що налагодження може бути болем.

Однак ми його зараз не вимикаємо. Ми майже завжди продовжуємо це працювати. Я час від часу вимикаю його, щоб швидко перевірити, чи є проблема SElinux чи ні.

Налагодити налагодження набагато простіше, особливо якщо ви знайомитесь з аудиторією2. Вам не потрібно це розуміти за допомогою audit2allow, але ви можете в деяких випадках відкрити тонкіші ширші, ніж ви думаєте, з Aud2allow. Сказавши, що деякий SELinux кращий за жоден.

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

Головне , я повинен був використовувати , є ls -lZ(контекст SELinux шоу), audit2allow, chcon, semodule, getenforce, setenforceі булеві. За допомогою цих інструментів мені вдалося отримати всі програми, необхідні для роботи під SELinux.

Я вважаю, що одна з великих проблем з налагодженням проблем SELinux, - це просто перемикання, щоб перевірити проблеми SELinux, коли у мене є інші мудрі незрозумілі проблеми. Зазвичай мені потрібно трохи хитрість, щоб поїхати "h! Перевірити SELinux !!".

Згідно зі сторінкою "Bind man", SELinux набагато безпечніше, ніж біг в'язниці в тюрмі Chroot. Дуже багато людей, які мають набагато більше підказки, ніж я також рекомендую, тому я зараз виконую його сліпо. І підозрюючи, незважаючи на випадкові проблеми, це, мабуть, варто зробити.

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

Немає причин вимикати його, коли можна запустити його в режимі Permissive. Він не заважатиме запущеному додатку, і він все ще забезпечить корисний журнал безпеки. Єдиний виняток стосується контекстів користувачів: якщо ви змінюєтесь між різними користувачами, які живуть в іншому екземплярі Linux, що працює в chroot, у вас можуть виникнути проблеми.

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