Apacheをchroot刑務所に入れる価値がないのはいつですか？
ほとんどのシナリオでApacheをchroot-jailに入れるという、十分に確立されたセキュリティ対策に疑問を呈するつもりはありませんが、私のシナリオでは疑問があります。
単一のアプリケーション（Webサービス）をホストする仮想サーバーがあります。このガイドは私がすべきだと言っています SELinuxを無効にする これは私には安全性が低いようですか？アプリケーションが危険にさらされた後のCentosインストールの実行を保護するためのすべて。
明らかにこれは少し主観的ですが、リソースが限られている小規模な展開では、焦点を当てるべきより良いアプローチがありますか？
Chrootは、攻撃者にスピードバンプを提供するために、わずかなセキュリティを提供します。 Apache/CGIに脆弱性がある場合、攻撃者はchrootジェイルから脱出する必要があります。自動化された攻撃がこれを行おうとする可能性は低くなりますが、既知のカーネルエクスプロイトがあり、そのエクスプロイトの要件がchrootされた環境で取得できる場合は、うんざりします。
SELinuxが提供するセキュリティはより大きなものですが、実装の苦痛はくしゃみをする必要はありません。単純なケースでは、事前に用意されたSELinuxポリシーがあるかもしれませんが、奇妙な/カスタムの作業をしている場合は、それらを自分で拡張する必要があります。 selinux開発RPMがロードされている場合、これはそれほど難しいことではありません。非強制モードで開始し、システムを完全に実行してから、次を実行します。
audit2allow -a -l -R -m foo -o foo.te
これは、カスタムポリシーの作成に役立ちます。
SELinuxと同様のステップはGRSecurityです。これは標準的ではありませんが、おそらくSELinuxの方が少し安全で、おそらく少し使いやすいですが、インターネット上のランダムな人が少ないのであなたを助けることができます。
別のアプローチは、VMでWebサーバーを実行することです。これによりセキュリティが少し強化されますが、攻撃はVM環境から逃れることができることが知られています。ただし、通常のスクリプトキディではなく、非常に断固とした攻撃者である可能性があります。
Chroot環境でApacheをセットアップするのに苦労したことがないことを捨てます。 chrootが必要ないと考えている場合は、おそらく必要ありません。