Dockerコンテナでアプリケーションを実行しようとしています。このアプリケーションを実行するにはroot権限が必要です。
sudo docker run --restart always --network host --cap-add NET_ADMIN -d -p 53:53/udp my-image
私の質問は：--networkホストオプションを使用してNET_ADMIN機能を追加する際のリスクは何ですか？
攻撃者が自分のアプリケーションでいくつかのコードを実行できる場合、rootとして実行しているので、攻撃者は無制限の権限を持っていますか、それともカーネルのネットワーク部分にのみアクセスできますか？それでは、彼の攻撃面は何ですか？つまり、NET_ADMIN機能セットのみを使用してホストOSからroot権限を取得できますか？
ベストアンサー1
Q1.攻撃者はNET_ADMIN関数のみを使用して自分のホストオペレーティングシステムのroot権限を取得できますか？
はい（場合によっては）。
CAP_NET_ADMINSIOCETHTOOL名前空間内のすべてのネットワークデバイスでioctl（）を使用できます。これにはETHTOOL_FLASHDEVieなどのコマンドが含まれますethtool -f。
これがゲームです。詳細な説明は、以下の引用にあります。
SIOCETHTOOLすべてのネットワーク名前空間で許可されています。5e1fccc0bfac 送信、「net：ユーザーのルートがネットワークスタックのコアを制御できるようにします」。以前は、CAP_NET_ADMIN「root」ネットワークネームスペースでのみこれが可能でした。これは当時の安全上の考慮事項が言及されたので興味深いものです。私は見ましたカーネルバージョン5.0のコード、私は次のコメントがまだ適用されると思います。
Re: [PATCH net-next 09/17] net: ネットワークスタックのコアに対するユーザーのルート制御を許可します。
同じ理由で、user_nsで許可されているethtoolコマンドをオプションで選択するのが最善です
CAP_NET_ADMIN。これを最初に考慮しなさい:
ETHTOOL_SEEPROM=> NIC Brick
ETHTOOL_FLASHDEV=> IOMMUを使用しない場合はNICを所有します。デフォルトでは、物理ハードウェアにアクセスできない場合は、これらの問題を回避できます。物理ネットワークインターフェイスにアクセスするには、ネットワークネームスペースに移動する必要があります。
はい、知っています。問題は、物理ネットワークデバイスが割り当てられていても、コンテナのどれがこれらのタスクを実行できると期待しているかです。
実際にコンテナを考慮しなくても、同じ質問があります。
CAP_NET_ADMINネットワークハードウェアなので、実際にハードウェアの低レベル制御を提供する必要がありますか？これらのethtool操作の一部と非標準MDIOレジスタへのアクセスには、追加機能（CAP_SYS_ADMINまたはCAP_SYS_RAWIO？）が必要な場合があると思います。
そうだと思います。封じ込め関数にも同様の問題があります。検索中に結果にロックされたパッチが見つかりませんでした。機能をロックする解決策は、署名のみを許可するカーネルモジュールをロックするのと同様のデジタル署名の一種であると思います。
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フックを見つけられませんでした。
Ben Hutchingsが良い点を指摘したと思います。理想的な解決策はこれをCAP_SYS_RAWIO。あなた：-P。 （特にセーフブートがこの問題に対処する場合）その後、変更が元に戻り、最も見苦しいハッキングが何であるかを判断できます。
つまり、カーネルは以前のバージョンとの互換性を維持し、CAP_NET_ADMINルート名前空間のプロセスを許可するように強制することができます。この場合もseccomp-bpfdocker コマンドを保護する必要があります。この場合、カーネルを変更しようとする価値があるかどうかはわかりません。カーネルは（一部）コンテナのみを保護するためです。たぶんコンテナランタイムがデフォルトでブロックされるように変更するdockerことができます。SIOCETHTOOLこれは、LXC / systemd-nspawnなどの「OSコンテナ」の動作デフォルトでもあります。