Loading article…
chrootchroot は、 UnixおよびUnix ライクなオペレーティングシステムにおけるシェルコマンドおよびシステムコールであり、現在実行中のプロセスとその子プロセスの見かけ上のルートディレクトリを変更します。このように変更された環境で実行されるプログラムは、指定されたディレクトリツリー外のファイルに名前を付けることができず（したがって、通常はアクセスできません）。 chrootという用語は、chroot(2)システムコールまたはchroot(8)コマンドラインユーティリティを指す場合があります。変更された環境はchroot jailと呼ばれます。
chrootシステムコールは、 1979 年にバージョン 7 Unixの開発中に導入されました。ある情報源によると、ビル・ジョイは、インストールとビルド システムをテストするために、4.2BSDがリリースされる17 か月前の1982 年 3 月 18 日にこれを追加したとのことです。 [ 1 ]カーネルを持つすべてのバージョンの BSD にはchroot(2)があります。[ 2 ] [ 3 ] chrootに適用された「jail」という用語の初期の使用例は、ビル・チェスウィックが1991 年にハッカーを監視するためにハニーポットを作成したことに由来します。[ 4 ]
脱獄に関する最初の記事は、Carole Fennelly が執筆するSunWorld Onlineのセキュリティ コラムで取り上げられました。1999 年 8 月号と 1999 年 1 月号では、 chroot()のトピックのほとんどが網羅されています。[ 5 ]
仮想化に役立つように、FreeBSD はこの概念を拡張し、2000 年の 4.0 リリースでjailコマンドを導入しました。[ 6 ]
2002年までに、ニコラ・ボワトゥーによるフランス語の記事で、Linux上でjailを作成する方法が説明された。[ 7 ]
2003年までに、 Linux jails を備えた最初のインターネットマイクロサービスプロバイダーが、使用量に応じて jail 内で消費されるSaaS / PaaS (シェル コンテナ、プロキシ、ircd、ボットなど) サービスを提供しました。 [ 8 ]
2005年までに、SunはSolaris Containers （Solaris Zonesとも呼ばれる）をリリースした。これは「強化版chroot」と評されている。[ 9 ]
2008年までに、LXC（後にDockerが構築された基盤）は「コンテナ」という用語を採用し[ 10 ] 、2013年にLinuxカーネル3.8にユーザーネームスペースが組み込まれたことで人気が高まりました。[ 11 ]
chroot環境を使用すると、ソフトウェアシステムの仮想化されたコピーを別途作成してホストできます。これは次のような場合に役立ちます。
chroot メカニズムは、特権 (root) ユーザーによる意図的な改ざんを防ぐことを目的としたものではありません。注目すべき例外はNetBSDで、chroot はセキュリティ メカニズムとみなされており、脱出方法は知られていません。ほとんどのシステムでは、chroot コンテキストは適切にスタックされないため、十分な権限を持つ chroot されたプログラムは、2 回目の chroot [ 12 ]を実行して脱出する可能性があります。このセキュリティ上の弱点のリスクを軽減するために、chroot されたプログラムは、chroot 後できるだけ早く root 権限を放棄するか、FreeBSD の jails などの他のメカニズムを使用する 必要があります。FreeBSD などの一部のシステムでは、2 回目の chroot 攻撃を防ぐための対策が講じられていることに注意してください。[ 13 ]
通常のファイルシステム上でデバイスノードをサポートするシステムでは、chrootされたrootユーザーでもデバイスノードを作成し、そこにファイルシステムをマウントすることができます。したがって、chrootメカニズム自体は、特権ユーザーによるシステムデバイスへの低レベルアクセスをブロックするために使用することを意図したものではありません。また、I/O、帯域幅、ディスク容量、CPU時間などのリソースの使用を制限することも意図していません。ほとんどのUnix系OSは完全にファイルシステム中心ではなく、ネットワークやプロセス制御といった、潜在的にシステムに影響を与える可能性のある機能を、chrootされたプログラムへのシステムコールインターフェースを通じて利用できるようにしています。
起動時に、プログラムはスクラッチ領域、設定ファイル、デバイスノード、共有ライブラリをあらかじめ設定された特定の場所に見つけることを想定しています。chrootされたプログラムが正常に起動するには、chrootディレクトリにこれらのファイルの最小限のセットを配置する必要があります。このため、chrootを一般的なサンドボックスメカニズムとして使用するのは困難です。Jailkit [ 14 ]などのツールは、このプロセスを簡素化および自動化するのに役立ちます。
chrootを実行できるのはrootユーザーのみです。これは、ユーザーが特別に細工されたchroot環境（例えば、偽の/etc/passwdファイルと/etc/shadowファイルを含む）内にsetuidプログラムを配置し、権限昇格を企むことを防ぐためのものです。
一部のUnix系OSは、これらの制限の少なくとも一部に対処するためにchrootメカニズムの拡張機能を提供しています（オペレーティングシステムレベルの仮想化技術の実装を参照）。
chroot 環境でグラフィカル アプリケーションを実行するには、次のような方法を使用できます。[ 15 ] [ 16 ]
Postfixメール転送エージェントは、個別にchrootされたヘルパープログラムのパイプラインとして動作する可能性がある。[ 18 ]
4.2BSD と同様に、Debian と Ubuntu の内部パッケージ構築ファームは、パッケージ間の意図しないビルド依存関係を検出するために chroot を多用しています。SUSEもビルドプログラム で同様の方法を使用しています。Fedora 、Red Hat、およびその他のさまざまなRPM ベースのディストリビューションは、mockなどの chroot ツールを使用してすべてのRPM をビルドします。
POSIXシステム向けの多くのFTPサーバーは、信頼できないFTPクライアントをサンドボックス化するためにchrootメカニズムを使用します。これは、着信接続を処理するプロセスをフォークし、その子プロセスをchrootすることで実現できます（プログラムの起動に必要なライブラリをchroot環境に配置する必要がないようにするため）。
特権分離が有効になっている場合、OpenSSHデーモンは、各クライアントの事前認証ネットワークトラフィックを処理するために、特権のないヘルパープロセスを空のディレクトリに chroot します。デーモンは、SFTP およびシェルセッションを chroot 内でサンドボックス化することもできます (バージョン 4.9p1 以降)。[ 19 ]
ChromeOSはchrootを使用してCrouton [ 20 ]を使ってLinuxインスタンスを実行でき、そうでなければ軽量なOSにハードウェアリソースへのアクセスを提供します。この記事で説明するセキュリティ上の問題は、ここにも適用されます。
Linuxで機能的なchroot環境を構築するには、カーネルの仮想ファイルシステムと設定ファイルもホストからchroot環境にマウント/コピーする必要があります。
# カーネル仮想ファイルシステムをマウントするTARGETDIR = "/mnt/chroot" mount -t proc proc $TARGETDIR /proc mount -t sysfs sysfs $TARGETDIR /sys mount -t devtmpfs devtmpfs $TARGETDIR /dev mount -t tmpfs tmpfs $TARGETDIR /dev/shm mount -t devpts devpts $TARGETDIR /dev/pts# /etc/hosts をコピー /bin/cp -f /etc/hosts $TARGETDIR /etc/# /etc/resolv.conf をコピーします /bin/cp -f /etc/resolv.conf $TARGETDIR /etc/resolv.conf# /etc/mtab をリンクする chroot $TARGETDIR rm /etc/mtab 2 > /dev/null chroot $TARGETDIR ln -s /proc/mounts /etc/mtab