web-dev-qa-db-ja.com

NET_ADMIN機能を備えたアプリを実行しているDocker：関連するリスク

Dockerコンテナーでアプリを実行しようとしています。アプリを実行するには、root権限が必要です。

Sudo docker run --restart always --network Host --cap-add NET_ADMIN -d -p 53:53/udp my-image

私の質問は、NET_ADMIN機能を--network Hostオプションと一緒に追加する場合のリスクは何ですか？.

攻撃者が何らかの方法でアプリからコード実行を取得できる場合、私はそれをrootとして実行しているので無制限の能力を持っているのですか、それともカーネルのネットワーク部分にしかアクセスできないのですか？もしそうなら、彼の攻撃面は何でしょうか（つまり、NET_ADMIN機能のみが設定されている私のホストOSでrootを獲得できますか？）

rootdockercapabilities
3
Doesntmatter

Q1。攻撃者はNET_ADMIN機能のみを使用してホストOSでrootを獲得できますか？

はい（場合によっては）。

CAP_NET_ADMINを使用すると、名前空間内の任意のネットワークデバイスでSIOCETHTOOL ioctl（）を使用できます。これには、ETHTOOL_FLASHDEV、つまりethtool -fなどのコマンドが含まれます。

それがゲームです。以下の引用にもう少し説明があります。

commit 5e1fccc0bfac 、 "net：ネットワークスタックのコアのusernsルート制御を許可する"ので、SIOCETHTOOLはすべてのネットワーク名前空間内で許可されます。それ以前は、「ルート」ネットワーク名前空間のCAP_NET_ADMINのみが可能でした。当時指摘されていたセキュリティ上の考慮事項のため、これは興味深いものです。私は カーネルバージョン5.0のコード を見て、次のコメントがまだ当てはまると思います。

Re：[PATCH net-next 09/17] net：ユーザーがネットワークスタックのコアをrootで制御できるようにします。

同じ理由で、user_nsごとのCAP_NET_ADMINに基づいて、どのethtoolコマンドが許可されるかについて非常に選択する必要があります。開始を検討してください：

ETHTOOL_SEEPROM => NICをブリック
ETHTOOL_FLASHDEV => NICをブリックします。 IOMMUを使用していない場合はシステムを所有する

これらは、デフォルトで実際のハードウェアにアクセスできないことにより防止されます。物理ネットワークインターフェイスにアクセスするには、物理​​ネットワークインターフェイスをネットワーク名前空間に移動する必要があります。

はい、わかりました。問題は、物理的なネットデバイスが割り当てられている場合でも、コンテナー内の何かがそれらのことを実行できると期待するかどうかです。

実際には、コンテナを考慮せずに同じ問題があります-CAP_NET_ADMINは、ハードウェアがネットワークハードウェアであるという理由だけで、ハードウェアを低レベルで制御する必要がありますか？これらのethtool操作の一部、および非標準のMDIOレジスタへのアクセスには、おそらく追加の機能（CAP_SYS_ADMINまたはCAP_SYS_RAWIO？）が必要になると思います。

lockdown 機能にも同様の問題があると思います。検索中に、結果にロックダウンパッチが表示されていることに気付きませんでした。ロックダウン機能のソリューションは、ロックダウンで署名されたカーネルモジュールのみが許可されるのと同様の、ある種のデジタル署名であると思います。

Q2。彼らがどういうわけか私のアプリから何らかのコード実行を取得した場合、彼らは無制限の力を持っていますか？

私はこれをあなたのコマンドに固有のより狭いケースとして分割しています-

Sudo docker run --restart always --network Host --cap-add NET_ADMIN -d -p 53:53/udp my-image

機能だけでなく、dockerコマンドもseccompの制限を課す必要があります。また、システム（SELinuxまたはAppArmor）で使用可能な場合は、LSMベースの制限が課される場合もあります。ただし、これらのいずれもSIOCETHTOOLには適用されないようです。

seccomp-bpfを使用してSIOCETHTOOLをブロックできると思います。ただし、 dockerのデフォルトのseccomp構成 は、ioctl（）呼び出しのフィルタリングを試みません。

そして、私が調べたカーネル関数にLSMフックがあることに気づきませんでした。

ベン・ハッチングスは良い点を作ったと思います。理想的な解決策は、これをCAP_SYS_RAWIOに制限することです。しかし、あなたがそのようなものを変更し、あまりに多くの人々が「気づく」場合-つまり、それは彼らの設定を壊します-そしてあなたは怒っているLinusがあなたに向かって叫ぶことになります:-P。 （特に「セキュアブート」のためにこれに取り組んでいる場合）。その後、変更が元に戻され、最も醜いハックが何であるかがわかります。

つまりカーネルは下位互換性を維持するように強制され、ルート名前空間にCAP_NET_ADMINを持つプロセスを許可する場合があります。その場合でも、Dockerコマンドを保護するにはseccomp-bpfが必要です。 （一部の）コンテナーのみを保護するため、この場合はカーネルを変更する価値があるかどうかはわかりません。また、dockerのようなコンテナランタイムは、デフォルトでSIOCETHTOOLをブロックするように修正できます。それはLXC/systemd-nspawnのような「OSコンテナ」の実行可能なデフォルトでもあるかもしれません。

2
sourcejedi