MySQLを実行するDockerコンテナー(LXC)があります。Dockerの背後にあるアイデアは一般に「コンテナごとに1つの実行プロセス」であるので、MySQLバイナリをターゲットとするAppArmorプロファイルを定義すると、それらは適用されますか?これをテストする方法はありますか?
cgroups
が、それほどではありません。申し訳ありませんが安全である方がいいです。MySQLゼロデイにcgroupから抜け出す方法を見つけるよりも、MySQLをロックダウンさせたいです。
MySQLを実行するDockerコンテナー(LXC)があります。Dockerの背後にあるアイデアは一般に「コンテナごとに1つの実行プロセス」であるので、MySQLバイナリをターゲットとするAppArmorプロファイルを定義すると、それらは適用されますか?これをテストする方法はありますか?
cgroups
が、それほどではありません。申し訳ありませんが安全である方がいいです。MySQLゼロデイにcgroupから抜け出す方法を見つけるよりも、MySQLをロックダウンさせたいです。
回答:
まず、cgroupは、アプリケーションをシステム上の他のアプリケーションから分離するために使用されません。これらは、リソースの使用状況とデバイスへのアクセスを管理するために使用されます。いくつかの(制限された)分離を提供するのは、さまざまな名前空間(PID、UTS、マウント、ユーザー...)です。
さらに、Dockerコンテナー内で起動されたプロセスは、それが実行されているAppArmorプロファイルを管理できない可能性があります。現在採用されているアプローチは、コンテナを起動する前に特定のAppArmorプロファイルをセットアップすることです。
Dockerのlibcontainer実行ドライバーは、コンテナーのAppArmorプロファイルの設定をサポートしているようですが、ドキュメントに例や参照がありません。
AppArmorはUbuntuのLXCでもサポートされているようです。
アプリケーションのAppArmorプロファイルを記述し、LXC / libcontainer / Docker / ...がコンテナ内のプロセスを開始する前にそれをロードすることを確認してください。
この方法で使用されるプロファイルは強制する必要があり、それをテストするには、不正なアクセスを試み、失敗することを確認する必要があります。
この場合、バイナリと実際に適用されるプロファイルの間にリンクはありません。コンテナーにこのプロファイルを使用するようにDocker / LXCに明示的に指示する必要があります。MySQLバイナリのプロファイルを作成すると、コンテナではなく、ホストでのみ適用されます。
答えは非常にありそうです:いいえ。
UbuntuのサーバガイドトピックLXCはほとんどあなたの正確な質問について説明し、次の文を作ります:
コンテナー内のプログラムをさらに制限することはできません。たとえば、MySQLは(ホストを保護する)コンテナープロファイルで実行されますが、MySQLプロファイルに入る(コンテナーを保護する)ことはできません。
悪用による望ましくない影響を回避するためのより良いオプションは、コンテナーを実行しているユーザーを制限し、カーネルのユーザー機能を活用するユーザースペースLXCコンテナーを使用することです。ただし、docker
現在-私の知る限り-はサポートされていませんuserns
。
そのような場合、MySQLは(ホストの観点から)非特権ユーザーとして実行されますが、コンテナー内ではとして実行されroot
ます。その後iptables
、必要に応じて、を使用してMySQLをホストの外部ポートにバインドできます。