chrootは、UnixおよびUnix系オペレーティングシステムにおけるシェル コマンドおよびシステムコールであり、現在実行中のプロセスとその子プロセスの見かけ上のルートディレクトリを変更します。このように変更された環境で実行されるプログラムは、指定されたディレクトリツリー外のファイルに名前を付けることができず（したがって、通常はアクセスできません） 。chrootという用語は、chroot(2)システムコールまたはchroot(8)コマンドラインユーティリティを指す場合があります。変更された環境はchroot jailと呼ばれます。
chrootシステムコールは、1979年のバージョン7 Unixの開発中に導入されました。ある情報源によると、ビル・ジョイは1982年3月18日（4.2BSDがリリースされる17ヶ月前）に、インストールとビルドシステムをテストするためにこれを追加しました。[1]カーネルを持つすべてのBSDバージョンにはchroot(2)があります。[2] [3] chrootを指す「jail」という用語が最初に使われたのは、ビル・チェスウィックが1991年にハッカーを監視するためのハニーポットを作成したことに由来します。[4]
脱獄に関する最初の記事は、キャロル・フェネリーが執筆したSunWorld Onlineのセキュリティコラムで取り上げられました。1999年8月号と1999年1月号ではchroot()に関するほとんどのトピックが取り上げられています。[5]
FreeBSDは仮想化に役立てるためにこの概念を拡張し、2000年の4.0リリースでjailコマンドを導入しました。[6]
2002年までに、ニコラ・ボワテューが書いた記事で、Linux上でjailを作成する方法が説明されました。[7]
2003年までに、Linux jailを備えた最初のインターネットマイクロサービスプロバイダーは、使用量に応じてjailに課金されるSAAS / PAAS（シェルコンテナ、プロキシ、ircd、ボットなど）サービスを提供しました。[8]
2005年、Sunは「ステロイドを使ったchroot」と評されるSolarisコンテナ（Solarisゾーンとも呼ばれる）をリリースした。 [9]
2008年までに、LXC（後にDockerが構築された）は「コンテナ」という用語を採用し[10] 、2013年にはLinuxカーネル3.8にユーザー名前空間が組み込まれたことで人気を博しました[11]。
chroot環境は、ソフトウェアシステムの 仮想化された別コピーを作成し、ホストするために使用できます。これは次のような場合に役立ちます。
chrootメカニズムは、特権（root）ユーザーによる意図的な改ざんを防ぐためのものではありません。注目すべき例外はNetBSDで、chrootはセキュリティメカニズムとみなされており、脱出方法は知られていません。ほとんどのシステムではchrootコンテキストが正しくスタックされず、十分な権限を持つchrootされたプログラムは2回目のchrootを実行して抜け出す可能性があります。このセキュリティ上の弱点のリスクを軽減するには、chrootされたプログラムはchroot後できるだけ早くroot権限を放棄するか、FreeBSD jailなどの他のメカニズムを代わりに使用する必要があります。FreeBSDなどの一部のシステムでは、2回目のchroot攻撃を防ぐための予防措置が講じられていることに注意してください。[12]
通常のファイルシステム上でデバイスノードをサポートするシステムでは、chrootされたルートユーザーはデバイスノードを作成し、そこにファイルシステムをマウントすることができます。したがって、chrootメカニズム自体は、特権ユーザーによるシステムデバイスへの低レベルアクセスをブロックするために使用することを意図したものではありません。I /O、帯域幅、ディスク容量、CPU時間などのリソースの使用を制限することを意図したものではありません。ほとんどのUnixは完全にファイルシステム指向ではなく、ネットワークやプロセス制御といった潜在的に混乱を招く機能は、chrootされたプログラムへのシステムコールインターフェースを通じて利用可能です。
プログラムは起動時に、スクラッチ領域、設定ファイル、デバイスノード、共有ライブラリが特定の場所に配置されていることを期待します。chrootされたプログラムが正常に起動するには、chrootディレクトリにこれらのファイルの最小限のセットが配置されている必要があります。そのため、chrootを一般的なサンドボックス機構として使用することは困難です。Jailkitなどのツールは、このプロセスを簡素化および自動化するのに役立ちます。
chrootを実行できるのはrootユーザーのみです。これは、ユーザーがsetuidプログラムを特別に細工されたchroot jail（例えば、偽の/etc/passwdファイルや/etc/shadowファイルなど）内に置き、権限昇格を企てることを防ぐことを目的としています。
一部の Unix では、これらの制限の少なくとも一部に対処するために chroot メカニズムの拡張が提供されています ( 「オペレーティング システム レベルの仮想化テクノロジの実装」を参照)。
chroot環境上でグラフィカルアプリケーションを実行するには、次のような方法があります。[13] [14]
Postfixメール転送エージェントは、個別にchrootされたヘルパープログラムのパイプラインとして動作する場合がある。[16]
以前の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以降）。[17]
ChromeOSはchroot環境を利用してCrouton [ 18]を用いたLinuxインスタンスを実行できるため、本来は軽量なOSでありながらハードウェアリソースへのアクセスが可能になります。本稿で言及されているセキュリティ上の問題は、ここにも当てはまります。
Linux で機能的な chroot 環境を実現するには、カーネルの仮想ファイル システムと構成ファイルもホストから chroot にマウント/コピーする必要があります。
# カーネル仮想ファイルシステムをマウントする
TARGETDIR = "/mnt/chroot"
mount -t proc proc $TARGETDIR /proc
マウント -t sysfs sysfs $TARGETDIR /sys
マウント -t devtmpfs devtmpfs $TARGETDIR /dev
マウント -t tmpfs tmpfs $TARGETDIR /dev/shm
マウント -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