StackOverflowに関するこの質問の行と、ここにいる全く異なる群衆について、私は疑問に思います：SELinuxを無効にする理由は何ですか？引き続き有効にしますか？SELinuxをオンにしておくと、どのような異常が発生しましたか？Oracle以外に、SELinuxが有効になっているシステムのサポートに問題があるベンダーは他にありますか？
おまけの質問：誰かが強制的にターゲットモードでSELinuxを使用してRHEL5でOracleを実行できるようになりましたか？つまり、strictは素晴らしいことですが、それはまだリモートでも可能ではないので、まずはターゲットを絞ってください;-)
回答:
RedHatはより安全であるため、デフォルトでSELinuxをオンにします。Redhatから派生した製品を使用するほとんどすべてのベンダーは、SELinuxをオフにします。理由は、その理由がわからない理由を突き止めるために時間（つまりお金）を費やす必要がないためです。Redhat / Fedoraの人々は膨大な時間と労力を費やしてSELinuxをエンタープライズで実行可能なオプションにしていますが、他の多くの組織はあなたのセキュリティを本当に気にしません。（彼らは気に彼らのセキュリティとは全くの別物である自社の製品、セキュリティの評判。）
あなたがそれを機能させることができるなら、それのために行きなさい。できない場合は、ベンダーからの多くの支援を期待しないでください。おそらく、redhat / Fedoraの連中、selinuxメーリングリスト、およびfreenodeの#selinuxチャンネルから助けを得ることができます。しかし、オラクルのような企業から-まあ、SELinuxはビジネスプランを実際に考慮していません。
通常、SELinuxを完全に無効にするのではなく、Permissiveで実行する方が適切です。audit2whyしばらくしてから（を介して）通常の使用中に拒否された違反の種類を確認しaudit2allow、それらの「違反」がセットアップの誤検出である場合にカスタムポリシーを作成できます。
非Fedora派生システムでのSELinuxの動作は、デフォルトで典型的な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 Puppetモジュール：
オフにする理由は、デバッグが苦痛になる可能性があるためです。
ただし、今はオフにしません。ほぼ常に実行し続けます。SElinuxに問題があるかどうかをすばやく確認するために、時々オフにします。
特にaudit2allowで使い慣れた場合は、デバッグがはるかに簡単になります。audit2allowを使用して理解する必要はありませんが、audit2allowを使用するよりも広くシンを開く場合があります。いくつかのSELinuxが何よりも優れていると述べました。
私は決してSELinuxの専門家ではなく、数年しか使用していません。私はまだ基本を本当に理解していませんが、ディストリビューションに含まれているアプリや、ネットでコンパイルされたランダムなものを実行するのに十分な知識があります。
私が使用しなければならなかった主なものはありls -lZます（show SELinuxのコンテキスト）、 、audit2allow、chcon、、semodule およびブール値。これらのツールを使用して、SELinuxで実行するために必要なすべてのアプリを取得することができました。getenforcesetenforce
SELinuxの問題をデバッグする際に彼が抱える大きな問題の1つは、他に説明できない問題がある場合にSELinuxの問題をチェックすることだけを思い出すことです。通常、「h！check SELinux !!」に行くには少し苦労します。
bind manページによると、SELinuxはchroot jailでbindを実行するよりもはるかに安全です。私が推奨するよりもはるかに多くの手がかりを持っている他の多くの人々がいるので、私は盲目的にそれを実行します。そして、たまに起こる問題にも関わらず、おそらくやりがいがあると思われます。
Permissiveモードで実行できる場合は、オフにする理由はありません。実行中のアプリケーションに干渉せず、有用なセキュリティログを提供します。唯一の例外はユーザーコンテキストに関するものです。chrootで実行されている別のLinuxインスタンス内に住む異なるユーザー間で変更を行う場合、問題が発生する可能性があります。
SE Linuxは、以前ほど絶望的に不親切ではありません。少なくとも、RHEL5のような商業的にサポートされているディストリビューションにはありません。ほとんどの場合、そのままにしておくことができ、RedHatが提供するものなら何でも構いません。それ以外のものは可変です。問題は、Red HatやOracleなどの企業にとって、SE Linux対応のアプリケーションを動作させるためのプロフェッショナルサービスの仕事は素晴らしい収益源であり、すべてをうまく機能させるインセンティブがないことです。