KVM仮想マシンへのUSBイーサネットパススルーは、ネットワーク関連のカーネルの脆弱性を分離できますか？
NICドライバーやパケットフィルタリングなどのLinuxカーネルネットワークスタックがリモートの攻撃者に提供する攻撃面について心配しています。したがって、KVM仮想マシン（基本的には Qubes OS が行っていること）でネットワークコード（ドライバー、パケットフィルタリングなど）を分離することを計画していますが、タイプ1 xenハイパーバイザーの代わりにkvmを使用）
私の知る限り、これを達成するには2つの方法があります：マシンのIOMMUハードウェアを使用してDMAを分離できるという利点を持つ、PCIパススルーを使用してホストのイーサネットデバイスを通過させるか、USB経由で接続されたイーサネットデバイスを使用してUSBを通過させる仮想マシンへのデバイス。どちらの場合も、実際に低レベルのネットワーキングを行うのは仮想マシンカーネルです。私はメインボードのNICのPCIパススルーを使用しましたが、いくつかの理由でオプションにならないことが判明したため、イーサネットからUSBドングルへのUSBパススルーを調べています。
- 両方の方法（PCIおよびUSBパススルー）で、ネットワークに関してホストカーネルの攻撃面を実際に減らしていると思いますか？私の考えでは、このソリューションでは、ホストカーネルはデータを仮想マシンに渡すだけで、ネットワークトラフィックはホストカーネルのネットワークコードのどの部分にも影響を与えません。そうですか？
- 仮想マシンでのネットワークの分離を役に立たない/無意味にするUSB経由でデバイスを通過することで明白な問題はありますか？マシンの物理的なセキュリティについては心配していません。私は、ホストのUSB 3コントローラーが本来ならすべきではないことをするように説得するであろう、不正なUSBアダプターを接続する誰かから身を守る必要はありません。私の主な目標は、リモートエクスプロイトをより困難にすることです。
- 全体が失われた原因を追求していますか？例えば。仮想化を使用してシステムに大きな攻撃対象を追加する一方で、カーネルの実証済みの部分の穴について心配していますか？ KVMを使用してシステムの全体的なセキュリティを実際に低下させていますか？
攻撃表面の測定は難しいため、これは答えるのが難しい質問です。しかし、信頼できないデータがネットワーキングスタックの一部で通過する処理量であると私たちが考えるものによって「測定」すると仮定しましょう。
両方の方法（PCIおよびUSBパススルー）で、ネットワークに関してホストカーネルの攻撃面を実際に減らしていると思いますか？私の考えでは、そのソリューションでは、ホストカーネルはデータを仮想マシンに渡すだけで、ネットワークトラフィックはホストカーネルのネットワークコードのどの部分にも影響を与えません。そうですか？
私の知る限りでは、そうです。パススルー方式は、ホストOSがデータに対して行う処理を削減します。たとえば、その証拠はVirtualBoxのドキュメントにあります。
this feature allows to directly use physical PCI devices on the Host by the guest even if Host doesn't have drivers for this particular device.
これは、ホストOSがドライバーを使用して（PCI）パススルーデータを処理しないことを意味します。
仮想マシンでのネットワークの分離が役に立たない/無意味になるUSB経由でデバイスを通過することで明白な問題はありますか？マシンの物理的なセキュリティについては心配していません。私は、ホストのUSB 3コントローラーが本来ならすべきではないことをするように説得するであろう、不正なUSBアダプターを接続する誰かから身を守る必要はありません。私の主な目標は、リモートでの悪用をより困難にすることです。
here を読むことができるように、VirtualBoxはドライバーを使用してUSBパススルー管理を処理します。これは、ホストの攻撃面が、ドライバーが公開する面と同じ大きさであることを意味します。このドライバーはあなたのホストに住んでいます。したがって、これはトレードオフです。ホストにネットワークスタックを実行させるか、VMにプッシュして、必要なドライバーのみをホストに実行させます。これらのドライバーは（少なくともVirtualBoxでは）実際のデータは処理しませんが、念のため、攻撃対象として数えています。
全体が失われた原因を追求していますか？例えば。仮想化を使用してシステムに大きな攻撃対象を追加する一方で、カーネルの実証済みの部分の穴について心配していますか？ KVMを使用してシステムの全体的なセキュリティを実際に低下させていますか？
私はあなたがare全体としてホストの攻撃面を減らすと思いますただし、支払っている価格（複雑さ、実行時のペナルティ）は考慮されます。要件に応じて、設計上の決定を行う必要があります。
私の考えを要約すると：
あなたのソリューションは、パフォーマンスを犠牲にして攻撃面を減らすようです。ホストに残された攻撃面は存在しない（PCIパススルー）か、またはUSBデバイスを介したドライバーの処理のみVM 'クレーム'（USBパススルー）のいずれかになります。
はい、これにより、ホストカーネルの攻撃対象領域を減らすことができます。また、DMARテーブルが壊れていて、DMA攻撃から保護できない場合に、デバイスを分離するためにも役立ちます。これは、ほとんどのPCIデバイスに対して過去に行ったことです。検討する：
PCIパススルーではなくVFIOを使用します
VFIOはより新しく、デバイスを IOMMUグループ で適切に分離しますが、同じIOMMUグループ内にパススルーされていないデバイスがある場合、PCIパススルーはバイパスされる可能性があります。上記のリンクから：
IOMMUグループは、IOMMUの観点から分離されたと見なすことができるデバイスの最小セットを記述しようとします。 [...]レガシーKVM=デバイスの割り当てにより、ユーザーはこれらのデバイスを個別に割り当てることができますが、構成は失敗することが保証されます。VFIOはIOMMUグループによって管理されるため、これに最も違反する構成を防止しますIOMMU粒度の基本要件。
オプションROMに注意してください
ただし、注意すべき点が1つあります。 PCIデバイスを直接ゲストに渡すと、ゲストはオプションROMへの読み取り/書き込みアクセスを含む、PCI構成スペースへのrawアクセスを取得します。オプションROMは、特定のデバイスに保存された少しのファームウェアで、初期ブート時にBIOSによって実行されます。ゲストカーネルがハイジャックされた場合、ホストにエスケープできない場合でも、物理デバイス上のオプションROMに書き込み、次の再起動まで待つことができます。そのときに、オプションROMがBIOSによって呼び出されます。 BIOSルートキットを使用します。
ただし、このリスクを軽減する方法があります。 Intel TXTを使用すると、オプションROMを呼び出す前に確認できます。これには、ブート時にさまざまなTXT機能を有効にできるように、tbootを設定する必要があります。公式ドキュメントが利用可能 here 。これは非常に重要なので、無視しないでください！
ハードユーザースペースコンポーネント
はるかに多くの脆弱性がユーザースペースコンポーネント（QEMU、またはおそらくkvmtool）に存在するため、これを保護することは優先度が高いはずです。 QEMUを使用する場合は、-chrootディレクティブを使用して、ファイルシステムへのアクセスを空のディレクトリに制限する必要があります。 -runasディレクティブで専用の非特権ユーザーにドロップする必要があり、-sandboxディレクティブでseccompサンドボックスを有効にする必要があります。他の方法では、不要な機能（ACPI、RTCなど）を無効にし、リソース制限を設定することで、攻撃対象領域をさらに減らすことができます。 AppArmorやSELinuxなどのMACの使用も推奨されます。ソースからQEMUをコンパイルする場合は、正しいgccフラグを使用して、コンパイル時にさらに強化できます。
両方のカーネルを強化する
攻撃対象を減らしたい場合は、ホストとゲストの両方にgrsecurityを使用することが非常に重要です。さらに、grsecurityはPaXを提供します。PaXは、QEMUのようなユーザー空間コンポーネントを強化します。 QEMUを-enable-kvmと一緒に使用する場合は、最も厳しいPaX設定を使用しても安全です。 grsecurityの商用バージョンは必要ありません。すべてが頻繁に更新されない安定したカーネルです。高可用性サーバーを実行している場合を除き、これは必要ありません。