解決策 1:
@Some Guy が述べたように、これについては歴史的な観点から考える必要があります。
歴史的な観点からは、1 つのハードウェアが 1 つのオペレーティング システムの下にあるさまざまなサービスの 12 程度であるというものでした。 1 つのサービスが侵害された場合、そのハードウェア上のすべてが侵害されました。
仮想化では、これははるかに問題になりません。 VM から脱出することは不可能ではありませんが、簡単なことではありません。 VM から抜け出すことは、root 権限で実行されているプロセスが chroot から抜け出すことよりも確かに困難です。そのため、私のバインド サーバーは独自の VM で実行されています。その場合、被害は VM であるという事実だけですでに制限されているため、chroot の意味はあまりありません。
chroot は、VM のようなものを作成するための非常に脆弱な試みです。 chroot は、root 権限を持つ任意のプロセスからエスケープできます。 chroot は意図されたものではなく、セキュリティ メカニズムとして機能しません。 BSD ジェイルまたは LXC を使用した chroot は、OS レベルの仮想化を提供し、セキュリティ機能を提供します。しかし最近では、マシン全体の新しい VM をスピンアップするのが非常に簡単になっているため、この目的のためにセットアップしたり、OS レベルの仮想化ツールを使用する方法を学んだりする価値はありません。
bind の以前のバージョンでは、権限が削除されませんでした。 Unix では、root アカウントのみが 1024 未満のポートを開くことができ、Bind は udp/53 と tcp/53 でリッスンする必要があることを知っています。 Bind は root として開始され、特権を落とさないため、妥協はシステム全体が危険にさらされる可能性があることを意味します。最近のほとんどすべてのソフトウェアは、ソケットを開き始め、root 権限を必要とするその他の処理を行った後、実行しているユーザーを非権限アカウントに変更します。特権が削除されると、侵害された場合のホスト システムへの影響ははるかに少なくなります。
解決策 2:
他の答えはかなり良いですが、レイヤーでのセキュリティの概念について言及していません。システムに追加するセキュリティのすべての層は、敵対者が克服しなければならない別の層です。 BIND を chroot に入れると、もう 1 つの障害が追加されます。
BIND に悪用可能な脆弱性があり、誰かが任意のコードを実行できるとします。彼らがchrootにいる場合、システム内の他の何かに到達する前に、そこから抜け出す必要があります.前述のように、chroot 解除には root 権限が必要です。 BIND は root として実行されず、chroot で利用できる最小限のツールがあるはずであり、オプションがさらに制限され、本質的にシステム コールのみが残されます。権限をエスカレートするためのシステム コールがない場合、攻撃者は DNS レコードを調べたままになります。
SomeGuy が言及しているように、前述の状況はややありそうにありません。最近の BIND には脆弱性がほとんどなく、リモート実行ではなく DoS タイプのシナリオにほとんど制限されています。とは言うものの、chroot での実行はかなりの数の OS のデフォルト設定であるため、わずかに強化されたセキュリティを維持するためにあなたの側で努力する必要はほとんどありません。
解決策 3:
プリアンブル
インターネット上で人々が誤解を繰り返しているのを耳にします.. したがって、私はいくつかの説明をしようと思います
まず; 単純に原因と結果による偶然の発見がどれだけあったか 、最終的に何か他のに使用されました
Chroot監獄とは何か
Chroot は当初、プロセスまたはユーザーのルート ディレクトリを変更するように設計されました (未知のソースからソフトウェアをコンパイルするのに最適です)。これによりセキュリティが提供されました 簡単なクリーンアップを含む迅速なテスト ベッド アプライアンスと同様に、ベース システムに追加します。それから何年も経ち、その概念と暗黙の用途も同様に確かに変化しました.
chroot は効果的に使用されています であり、いくつかのコード ベースに直接含まれています。 プログラムとライブラリ (つまり、openSSHd、apache2 + mod_security2/mod_chroot、dovecot、sendmail、openVPN、pam_chroot、など ）。これらすべてのメインストリーム アプリケーションが不完全なセキュリティ ソリューションを実装していると仮定するのは正しくありません
chroot は、ファイル システム仮想化のソリューションです。それ以下でもそれ以上でもありません。 chroot から簡単に抜け出せるという仮定も真実ではありません... chroot 刑務所内でプロセスを実行するためのガイドラインを順守している限り.
chroot 監獄を保護するためのいくつかの手順
つまり、しない ROOT としてプロセスを実行します。これにより、ルート エスカレーション ベクトルが開かれる可能性があります (これは、chroot の内部または外部にも当てはまります)。内部でプロセスを実行しない 外部の別のプロセスと同じユーザーを使用する chroot ルート。攻撃面を制限し、プライバシーを提供するために、各プロセスとユーザーを独自の Chroot に分離します。必要なファイル、ライブラリ、およびデバイスのみをマウントします。最後に、chroot はベース システム セキュリティの代わりにはなりません。システム全体を保護します。
もう 1 つの重要な注意事項: 多くの人は、OpenVZ は壊れている、または完全なシステム仮想化と比較して同等ではないと考えています。これは本質的に Chroot であり、プロセス テーブルが無菌化されているためです。ハードウェアとデバイスにセキュリティ対策が施されています。 ほとんど chroot で実装できます。
すべての管理者が、専用サーバー上または完全なシステム仮想化下で必要なすべてのカーネル パラメーターを保護するために必要なレベルの知識を持っているわけではありません。これは、OpenVZ を展開することで、顧客がアプリケーションを展開する前に試行してカバーし、保護する攻撃面がはるかに少なくなることを意味します。優れたホストは、これらのパラメーターを適切に保護します。これは、ノード上またはデータセンター内のすべての人にとってだけでなく、インターネット全体にとってより良いものです...
述べたように、chroot はファイル システムの仮想化を提供します。 setuid 実行可能ファイル、安全でないアプリケーション、ライブラリ、ダングリング オーナーレス シンボリック リンクなどがないことを確認する必要があります。攻撃者がバインドを侵害する可能性がある場合、攻撃者は仮想ファイル システムを精査してバッファ オーバーランやファイル記述子の操作を行う必要があります。他の方法で、chroot 内に存在する何かを危険にさらし、通常は権限昇格または基本システムへのペイロードの注入によって刑務所を脱出します。
これが発生した場合、通常は不適切な更新、ゼロデイ エクスプロイト、または慣用的な人為的ミスが原因です。 .
完全なシステム仮想化ではなく、chroot がまだ使用されている理由
このシナリオを考えてみましょう:OpenVZ を実行しているホスト ノードで Virtual Private Server を実行しています。あなたは単にできません カーネル レベルで動作するものは何でも実行します。これは、オペレーティング システムの仮想化を使用してプロセスを分離し、追加のセキュリティを提供できないことも意味します。したがって、しなければならない この目的にはchrootを使用してください。
さらに、利用可能なリソースに関係なく、chroot はどのシステムでも持続可能です。簡単に言えば、どの仮想化タイプよりもオーバーヘッドが最小です。これは、多くのローエンド ボックスで依然として重要であることを意味します。
別のシナリオを考えてみましょう。仮想化環境内で実行されている apache があります。各ユーザーを分離したい。 Apache への chroot アドオン (mod_chroot、mod_security など) を介して仮想化されたファイル システムを提供することは、エンド ユーザー間の最大限のプライバシーを確保するための最良のオプションです。これは情報収集の防止にも役立ち、さらに別のセキュリティ層を提供します。
簡単に言えば、層にセキュリティを実装することが重要です . Chroot は潜在的にそれらの 1 つです。すべての人やすべてのシステムがカーネルにアクセスできるわけではないため、chroot STILL 目的を果たします。完全なシステム仮想化が本質的にやり過ぎであるさまざまなアプリケーションがあります。
ご質問への回答
私は特に CentOS を使用していませんが、Bind が操作の前にその特権を削除することを知っています。ただし、攻撃ベクトルの履歴と潜在的な脆弱性のために、bind は chroot されていると思います。
また...このアプリケーションを自動的にchrootする方が理にかなっています。なぜなら、誰もが完全なシステム/オペレーティングシステムレベルの仮想化にアクセスできるわけではないからです.これは、理論的には、CentOS ユーザー ベースにセキュリティを提供するのに役立ちます。
オペレーティング システムのプロバイダーは、すべてのプロバイダーが同じシステムを実行していると仮定して、動き回りません。このようにして、それらは全体として追加のセキュリティ層を提供するのに役立ちます...
非常に多くのアプリケーションがこれを使用する理由があります 、そして明らかにあなたのOSがデフォルトでそうする理由：それはセキュリティ機能として使用されており、機能するからです。前述のように、注意深い準備があれば、潜在的な攻撃者が克服しなければならないもう 1 つのハードルです。ほとんどの場合、chroot 監獄のみに被害を限定します。
解決策 4:
これは、古いバージョンの Bind に深刻なセキュリティ脆弱性が頻繁に発生していたという歴史的な理由によるものです。私はこの件について最新の情報を把握していませんが、古い時代から大幅に改善されていることは間違いありません.
より実用的なもう 1 つの理由は、通常、インターネットに面した役割で展開されるため、より多くの攻撃、調査、および一般的ないたずらにさらされる可能性があるということです。
したがって、セキュリティに関する経験則としてよくあることですが、特に chroot の手間が比較的少ないため、申し訳ありませんが安全です。