一部のユーザーがJavaアプリケーションを実行/テストするためにいくつかのchroot Jailを設定する予定です（各アプリケーションを信頼できないと仮定）。各刑務所に/ devと/ procをマウントする危険性はありますか？存在する場合、このリスクを排除するためにどのような措置を講じることができますか？
答え1
情報を公開し/procて/dev公開するほど、刑務所内のユーザーにはより多くの権利が与えられます。
UIDとGIDは刑務所の内部と外部で異なる場合があります。例えば、刑務所内では、ユーザ「ｘ」は、刑務所の「ユーザ」およびシステムの「ディスク」を表すグループ１２３のメンバーであってもよい。バインドマウントを使用すると、/devRAWディスクデバイスへのアクセスを許可し、仮想ルートアクセスを許可し、それを回避できます。
私はmount / devをバインドしません。 Javaアプリケーションに必要な適切な所有権と権限を持ついくつかのデバイス（null、、tty...）のみを作成してください。zero
chroot Jailの代わりにLinuxコンテナを使用することを検討しましたか？このコンテナはさらに隔離されています（lxcsはchroot Jailより一歩進んでいます）。
答え2
これはかなり大きなトピックであり、オンラインでこれについて多くの記事が登場しているので、一度読んでください。
基本的な要約は、chrootがセキュリティ機能として決して設計されていないことです。 root ユーザーは、さまざまな方法で chroot 刑務所を「エスケープ」することができ、一般ユーザーもさまざまな方法でエスケープできます。たとえば、chroot には別個のプロセス空間がないため、chroot 内のプロセスは、一般的なデバッグメカニズムを使用して外部プロセスに「接続」できます。一部の最新のディストリビューションでは、特定の攻撃をブロックする保護機能が有効になっていますが、すべてではありません。それにもかかわらず、rootユーザーは事実上これらすべての保護装置に免疫を与え、選択したファイルシステムをマウントするのを防ぐ方法はありません。
LXCはより良く、多くの最新のディストリビューションにも組み込まれていますが（私の考えでは）同じ問題があります（特に/ sysファイルシステムは乱用されやすい）。
OpenVZはより安全であることが知られていますが、設定がはるかに難しく、自分で試してみませんでした。