現在、安全なサンドボックス環境で信頼できないプログラム (学生の課題) を評価するプロジェクトを開始しています。主なアイデアは、LXC コンテナーを管理するために、GlassFish 用の Web アプリと lxc-utils の Java ラッパーを作成することです。待機中のプログラムのキューがあり、Java ラッパーが LXC コンテナーの固定数 (プール) を維持し、各プログラムに 1 つの (未使用の) コンテナーを割り当てます。
ホスト システムを保護するには、各コンテナを SELinux で保護する必要があります。
私の質問は、サンドボックス環境向けにこのようなメカニズムを作成するのは良い考えでしょうか、それともこの問題に対してもっと適切な解決策があるでしょうか。それは軽量で、学生の創造性に対して安全でなければなりません。
答え1
LXC は最も安全な仮想化ソリューションではないのに、なぜ LXC を選んだのか書いていません。私は KVM/XEN と LXC のヘビー ユーザーですが、セキュリティに関しては Linux コンテナー (LXC / OpenVZ / VServer のいずれであっても) は決して使用しません。KVM/XEN の方が簡単 (かつ信頼性が高い) だからです。
パフォーマンスやハードウェア要件に関するものであれば、LXC を試すことができますが、従うべきルールがいくつかあります。
- libvirt は、SELinux を使用するときにコンテナの厳密な制限を保証します (LXC_driver のおかげです) - ただし、これが RHEL/Centos/Fedora の場合だけかどうかはわかりません (Ubuntu/Debian はあまり使用しません)https://www.redhat.com/archives/libvir-list/2012-January/msg01006.html- したがって、SELinux を使用するのは良い考えです (私の意見では、このような状況では「必須」です)
- 厳格なcgroupsルールを設定して、ゲストがホストをフリーズさせたり、他のコンテナに影響を与えたりしないようにします。
- 私はLVMベースのコンテナを使いたいです。それは常にもう1つの「セキュリティ」レイヤーです。
- ネットワーク ソリューションとアーキテクチャについて考えてみましょう。それらのコンテナーは相互に通信する必要がありますか?
読むことから始めましょうこれ- かなり古いですが、それでも - そこには多くの知識があります。そしてまた - 会うユーザー名前空間
そして、そのすべてを終えた後でもう一度考えてみてください。本当に LXC のセキュリティを試すのにそんなに時間があるのでしょうか? KVM ははるかに簡単です...
答え2
信頼できないプログラムを実行するには、Linux 名前空間が依然として最適なソリューションです。KVM よりもセットアップが簡単で、必要なリソースも少なくて済みます。LXC を試すこともできますが、LXC は完全な Linux ディストリビューション イメージを実行するためのより汎用的なサンドボックスとして構築されました。他に 2 つの Linux 名前空間サンドボックスが思い浮かびます。