Docker：apparmor vs seccomp vs --cap-dropを使用する場合

Question

Dockerはapparmorとseccompの両方をサポートしているようです。 Dockerでは、コンテナーの実行時に機能を削除することもできます。

ただし、どのアプローチを使用するかに関するドキュメントやガイドラインは見つかりませんでした。

それらが何のために使用できるかにかなりのオーバーラップがあるようです、私はこれらのオプションのどれをいつ使用するべきかについての一般的なガイドラインを理解することができませんでした。

誰かがガイドラインを提供できますか？

私の場合、サーバー上で多くの学生コードを実行する必要があります。 Javaおよびc ++プログラムの実行を許可します。1つのディレクトリ（データボリューム）への書き込みアクセスを許可します。ネットワークアクセスや複雑なものを必要としません。

確保するためのガイドラインをいくつか提供してください。

forest · Answer

それらはすべて使用できます。

これらのセキュリティ機能にはそれぞれ異なる目的があり、実際にはほとんど重複していません。これらはすべて、プロセスが危険にさらされた後にプロセスが引き起こす可能性のある損害を軽減するように機能します。これらはすべて非常にオーバーヘッドが低く、ソフトウェアのセキュリティを大幅に向上させるために使用できます。

Seccomp は、ユーザースペースプログラムがsyscallフィルターを設定できるようにするLinuxの機能です。これらのフィルターは、許可されるシステムコールと、それらに許可される引数を指定します。これは、カーネルの攻撃対象領域を減らす非常に低レベルのフィルターです。たとえば、特権を昇格するためにそのsyscallへの単純な呼び出しを許可するkeyctl()のバグは、その呼び出しへのアクセスが制限されているプログラムのprivescで必ずしも使用できるとは限りません。

AppArmor は、LSM（Linux Security Module）として機能する必須アクセス制御フレームワークです。オブジェクト（ファイル、パスなど）へのサブジェクト（プログラム）のアクセスをホワイトリストまたはブラックリストに登録するために使用されます。 AppArmorを使用すると、プログラムは/etc/passwdに読み取りアクセスできますが、/etc/shadowにはできません。ポリシーを使用して、機能を制限したり、ネットワークアクセスを制限したりすることもできます。

Capabilities および機能の削除は、特権プロセスが付与された特権のサブセットを特権プロセスが取り消す一般的な手法です。ルートプロセスは、たとえば、ネットワークにそのままの接続を作成するために必要な機能や、ルートのままであっても標準のUNIXファイルアクセス許可（DAC）をバイパスするために必要な機能を削除できます。削除できる機能の数は限られているため、この手法は非常に細かいわけではありませんが、それでも、プログラムが侵害された場合にプログラムが受ける可能性のある損害は軽減されます。

一般に、次のことを知っておく必要があります。

Seccompは、カーネルの脆弱性が悪用される可能性を減らします。
AppArmorは、アプリケーションがアクセスすべきでないファイルにアクセスするのを防ぎます。
機能の低下により、侵害された特権プロセスが実行できるダメージが減少します。

参照サンドボックスはどのように実装されていますか？

Butshuti · Answer

@ forest でよく答えられましたが、セキュリティフレームワークとセキュリティ設計全般に関する私の見解を反映したいくつかの提案を追加したいと思います。セキュリティを強化することは、自分を何から保護しているのか、少なくとも何を保護しているのかを理解することにつながります。ただし、これらはすべてセキュリティポリシーから開始する必要があります。ポリシーが策定されると、選択が容易になります。いくつかのケースを考えてみましょう。ユースケースが反映されている場合とそうでない場合があります。ただし、それらを検討する前に、使用可能なオプションを次のように絞り込むと役立つ場合があります。

ターゲットプログラムを変更できない場合、MAC --Mandatory Access Control せいぜい）しかありません。必要なのは特定のプログラムが評価されるセキュリティポリシーを提供します。オペレーティングシステムのセキュリティレイヤーがプログラムを処理するため、プログラムや実装言語に関係なく。サンドボックスも選択肢の1つですが、カテゴリ3に分類されます。

プログラムを[再作成]している場合（または変更できる場合）：幸運を祈ります。実際に呼び出してセキュリティ対応プログラムを作成できるためです。選択したフレームワークによって提供される特定のセキュリティプリミティブ[詳細は下記]。ただし、選択したフレームワークのほとんどは低レベルである傾向があるため、プログラミング言語にバインディングがないという制限がある場合があります。それはC、Java、Go、Javascriptのどれですか（ええ、まるで！）ほとんどの場合、あなたは一人でいる可能性があるので、クラブへようこそ。しかし、オプションがあります。そして、ばかげたものもあります。

あなたは気にしないで、物があなたの顔で爆発しないようにしたいだけです（すなわち、上記のどれもあなたの時間の価値はありません）：sandboxesの場合、たぶん、VMのように劇的なものか、未知の気分になっている場合は、アプリケーションコンテナが親友です。ただし、最もセキュリティに精通しているマインドは、---（コンテナは含まないであることを警告しています。ただし、プログラムの内部を知る必要がなくても、少なくとも一部のリソース分離からは恩恵を受けます。 非特権コンテナを強くお勧めします。しかし、それ以外の場合、VMはまだクールです。

そして今、ケース：

悪意のある悪用の影響を受けない方法でプログラムを実行したい：それはanyを意味するため既知または未知の攻撃nothingは、要件を満たすことが保証されています（すべてのセキュリティフレームワークがこれを通知します）。しかし、少なくとも、プログラムを可能な限り少ないシステムコールに制限すると、攻撃対象領域が減少します。ただし、可能な方法の1％であっても、どこからでも攻撃を受ける可能性があります。ただし、アプリケーションから特権を取り除き、攻撃者にとっての有用性を低下させる場合は、システムコールフィルタリングと機能システムが役立ちます。 Seccomp （Linuxで使用可能）、 Capsicum （FreeBSDで使用可能、すぐにLinuxで使用可能）、および POSIX機能がここにあるオプションです。
プログラムを既知の/期待される動作に制限したい：簡単（単純なプログラムの場合）-アクセスしたファイルまたはカーネルオブジェクトに関して実行時の動作を定義できる場合、[〜＃〜] mac [〜＃〜]フレームワークが役立ちます（AppArmor、SELinuxなど）。ただし、ポリシーを表現する抽象化のレベルについても選択する必要があるため、正確さと柔軟性によってさまざまな方向に導きます（パスは十分に正確であり、iノードは管理可能であり、メモリセグメントはどうですか？）。
昇格された特権でプログラムを実行する必要があることに気づき、リスクが高すぎるのではないかと心配しています。機能の削除は、おそらく最も合理的なオプションです。これはOS固有です（他のすべてもそうです）が、特定のマシンでアクセス制御の一部として行われる場合、少なくとも実装に依存しません（言語で使用可能なバインディングに依存する、プログラムで機能インターフェースを呼び出すのとは対照的））。