Docker / LXCのAppArmorプロファイル


11

MySQLを実行するDockerコンテナー(LXC)があります。Dockerの背後にあるアイデアは一般に「コンテナごとに1つの実行プロセス」であるので、MySQLバイナリをターゲットとするAppArmorプロファイルを定義すると、それらは適用されますか?これをテストする方法はありますか?


なぜコンテナ内でapparmorを使いたいのですか?
c4f4t0r 2014

3
場合ゼロデイまたは他がアクセスすることがないように、データベースに対して実行されたエクスプロイトは何も他を。私はLinuxを信頼していますcgroups、それほどではありません。申し訳ありませんが安全である方がいいです。MySQLゼロデイにcgroupから抜け出す方法を見つけるよりも、MySQLをロックダウンさせたいです。
Naftuli Kay、2014

回答:


8

まず、cgroupは、アプリケーションをシステム上の他のアプリケーションから分離するために使用されません。これらは、リソースの使用状況とデバイスへのアクセスを管理するために使用されます。いくつかの(制限された)分離を提供するのは、さまざまな名前空間(PID、UTS、マウント、ユーザー...)です。

さらに、Dockerコンテナー内で起動されたプロセスは、それが実行されているAppArmorプロファイルを管理できない可能性があります。現在採用されているアプローチは、コンテナを起動する前に特定のAppArmorプロファイルをセットアップすることです。

Dockerのlibcontainer実行ドライバーは、コンテナーのAppArmorプロファイルの設定をサポートしているようですが、ドキュメントに例や参照がありません。

AppArmorはUbuntuのLXCでもサポートされているようです。

アプリケーションのAppArmorプロファイルを記述し、LXC / libcontainer / Docker / ...がコンテナ内のプロセスを開始する前にそれをロードすることを確認してください。

この方法で使用されるプロファイルは強制する必要があり、それをテストするには、不正なアクセスを試み、失敗することを確認する必要があります。

この場合、バイナリと実際に適用されるプロファイルの間にリンクはありません。コンテナーにこのプロファイルを使用するようにDocker / LXCに明示的に指示する必要があります。MySQLバイナリのプロファイルを作成すると、コンテナではなく、ホストでのみ適用されます。


これまでのところ、これは(限られた)経験です。Dockerコンテナー内からプロファイルを生成する際に問題が発生しましたが、プロファイルがコンテナーの外部で生成されてからコピーされた場合、実行可能ファイルを実行する前にコンテナーでAppArmorを開始すれば、それは正常に機能するはずです。
Naftuli Kay

@Siosm:LCX!= libcontainer。質問はLXCドライバーについてでした。
0xC0000022L 2014年

@ 0xC0000022L:AppArmorプロファイル実施モデルは、プロセスをコンテナーに制限するために使用されるツールと同じです。
Siosm 2014年

3

答えは非常にありそうです:いいえ。

UbuntuのサーバガイドトピックLXCはほとんどあなたの正確な質問について説明し、次の文を作ります:

コンテナー内のプログラムをさらに制限することはできません。たとえば、MySQLは(ホストを保護する)コンテナープロファイルで実行されますが、MySQLプロファイルに入る(コンテナーを保護する)ことはできません。

悪用による望ましくない影響を回避するためのより良いオプションは、コンテナーを実行しているユーザーを制限し、カーネルの機能を活用するユーザースペースLXCコンテナーを使用することです。ただし、docker現在-私の知る限り-はサポートされていませんuserns

そのような場合、MySQLは(ホストの観点から)非特権ユーザーとして実行されますが、コンテナー内ではとして実行されrootます。その後iptables、必要に応じて、を使用してMySQLをホストの外部ポートにバインドできます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.