☰

CAP_CHROOTがルートと同じ理由は何ですか？

tag-icon • tag-icon debian security chroot capabilities
CAP_CHROOTがルートと同じ理由は何ですか？

CAP_CHROOT次のテンプレートのルート同等性を理解できません。

1）は、すべての依存関係（共有オブジェクトなど）を含むディレクトリ構造を作成することを意味し、そのルートはchroot(2)。

私の質問には、テンプレートの次のステップが含まれます。

  • ld.soバックドアまたは2）が必要なのはなぜですかlibc？

  • 3）のchroot環境でsetuid-rootバイナリでハードリンクを作成する必要があるのはなぜですか？

  • chroot(2)4）で起動setuid-rootバイナリが呼び出されるのはなぜですか？

ここに画像の説明を入力してください。

ベストアンサー1

そうではない必要、これが方法です。

ルートディレクトリを変更すると、システムコンポーネントの前提が無効になります。

/bin/suユーザーデータベースが/etc/passwd/ /etc/shadow（libcまたはリンクされたライブラリ）に/lib通常のユーザーが変更できない固定場所にあるとします。

/bin/su同じコマンドを実行できますが、他のコマンドを自由に変更できる別のファイルシステムレイアウトを作成できる場合は、/etc/passwduseまたはuse（おそらく間接的に）を使用してユーザーを認証してコードを実行できます。libcsu/etc/passwd

今、このアプローチでは、CAP_CHROOT所有だけが必要ではありません。また、ファイルシステムのディレクトリへの書き込み権限も必要です（ハードリンクは以下を介してのみ実行できます）。以内に特定のファイルシステムの場合）動的にリンクされたsetuid-root実行可能ファイルが1つ以上あります。

システムにユーザーの書き込み可能領域（または読み取り専用領域）がないシステムパーティションがあることはまれではありません。ファイルシステムのユーザー書き込み可能領域がフラグを使用してマウントされることも一般的ですnosuid。また、多くのシステムでは、所有していないファイルへのハードリンクを無効にします（fs.protected_hardlinks例：Linux 3.6+のsysctlを参照）。

ただし、chroot刑務所の内部でsetuid実行可能ファイルをハードリンクする必要はありません。次のようにすることもできます。

chdir("/");
chroot("/tmp/myjail");
execl("bin/su", "su", 0);

これは、プロセスのルートディレクトリが変更されても、そのディレクトリとそこで確認されたディレクトリが利用できなくても、chroot後で現在の作業ディレクトリを引き続き使用できるためです。/bin/su~へ刑務所。絶対パスを介してアクセスされるので、それはまだ刑務所やlibcにあります/bin/su。ld.so/etc/passwdルート変更目次。現在の作業ディレクトリまたは刑務所の外部のファイルに開いているファイル記述子をそのままにしておくと、刑務所から出ることができるドアが提供されます。

おすすめ記事