潜在的に敵対的なネットワーク (インターネットなど) にさらされるサービスで、なぜこの方法を採用すべきなのか、明確な回答をいただきたいと思います。私の理解では、chroot jail から抜け出す方法があるはずです。このセキュリティ対策に実質的な価値がないのであれば、なぜ一部のインストールでは依然としてこの方法を採用しているのでしょうか。
答え1
chroot を完全なセキュリティ機能と見なすべきではありません。攻撃は難しくなりますが、chroot 内で何らかの制御が得られたとしても、抜け出すのは簡単です。親ディレクトリに chroot する方法があります (..) 詳細情報ここchroot がセキュリティ上の利点をもたらす理由は、ハッカーが想定している多くのアプリケーションが存在しないからです。chroot するかしないかの選択肢がある場合、私は chroot するオプションを選択します。
より良いアプローチとしては、BSD の jail、Solaris のゾーン、または KVM や Xen などの仮想化テクノロジのようなものが考えられます。これらのアプローチは、chroot と同じ区画化の考え方を採用しており、より強力になっています。SELinux のようなものを検討することもできますが、これは少し複雑であるため、間違いが起きやすくなります。
答え2
私の理解では、chroot jail から抜け出す方法はあるはずです (...) それでは、なぜ一部のインストールでは依然としてその方法を追求しているのでしょうか?
パスワードについても同じことが言えます。ポイントは、多くの場合、一部のリソースを保護するには、侵入者の進路に多くの障害物を配置して、侵入者がターゲットに到達する前に諦めるようにする必要があるということです。特定のリソースを保護するために、単一の方法に頼ることはできません。さらに、chroot を使用すると、実行中のアプリケーションをより細かく制御できます。このアプリがアクセスできるファイル システム リソースを制限できます。
答え3
はい、そうです。
- デーモンまたはサービスを提供しているものが root として実行されていない場合、そのデーモンのホールもシステムの残りの部分から分離されます。
- OSがchroot()中に実行できる操作を制限できるなら、それはさらに良いことです。たとえば、Linuxのgrsecパッチは、chroot内のrootユーザーが抜け出す能力を削除したり、chroot内に/dev-nodesを作成したりすることができます。
ただし、chroot 内で悪用可能なカーネル バグ (または、grsec や BSD jail でない場合は単なるルート ホール) が発生した場合、システム全体が乗っ取られます。実際の仮想化ツール (VMWare など、BSD jail ではありません。BSD jail はすべての「システム」に同じカーネルを使用するため役に立ちません) を実行している場合はそうではありません。
したがって、正しく使用すれば、セキュリティ レイヤーが追加されます。
答え4
chroot はあまりにも複雑すぎると思うので、インストールしたことがありません。インストールできたら、大いに興味を持つだろうと主張する人もいるかもしれませんが、まだ興味はありません。
最近のコンピューティング能力を考えると、仮想マシン (もちろん Xen 上ですが、VMWare でも動作します :-P ) でサービスを分離する方がはるかに良いアイデアだと思います。仮想マシンには、chroot にはない、バックアップや移行が非常に簡単であるという大きな利点もあります。また、VM を管理するための包括的なインターフェイスもありますが、これは chroot にはまったくありません。