QubesOS を使用して Windows 7 と連携する

Habré に関する Qubes オペレーティング システムに特化した記事はあまり多くありません。また、私が見た記事でも Qubes オペレーティング システムの使用体験についてはあまり説明されていません。このカットの下では、Windows 環境に対する保護手段として Qubes を使用する例を使用してこれを修正し、同時にシステムのロシア語を話すユーザーの数を推定したいと考えています。

なぜキュベスなのか？

Windows 7 のテクニカル サポート終了の話とユーザーの不安の増大により、次の要件を考慮してこの OS の作業を整理する必要が生じました。

• ユーザーが更新プログラムやさまざまなアプリケーション (インターネット経由を含む) をインストールできる機能を備えた、完全にアクティベートされた Windows 7 の使用を保証します。
• 条件（自律動作およびトラフィック フィルタリング モード）に基づいてネットワーク インタラクションを完全または選択的に除外します。
• リムーバブル メディアとデバイスを選択的に接続する機能を提供します。

この一連の制限は、独立した管理が許可されているため、ユーザーが明確に準備されていることを前提とし、制限はユーザーの潜在的なアクションのブロックではなく、起こり得るエラーやソフトウェアの破壊的な影響の排除に関連しています。それらの。このモデルには内部犯罪者は存在しません。

解決策を模索する中で、管理者権限を持つユーザーを効果的に制限し、アプリケーションをインストールできるようにすることは非常に難しいため、組み込みまたは追加の Windows ツールを使用して制限を実装するという考えはすぐに放棄されました。

次の解決策は、仮想化を使用した分離でした。デスクトップ仮想化用のよく知られたツール (たとえば、virtualbox など) はセキュリティ問題の解決にはあまり適しておらず、リストされている制限事項は、ユーザーがゲスト仮想マシン (以下、 VM として)、エラーのリスクが増加します。

同時に、私たちはユーザーのデスクトップ システムとして Qubes を使用した経験がありましたが、ゲスト Windows での動作の安定性に疑問がありました。記載されている制限事項がこのシステムのパラダイム、特に仮想マシン テンプレートと視覚的統合の実装に非常によく適合しているため、Qubes の現在のバージョンをチェックすることにしました。次に、問題を解決する例を使用して、Qubes のアイデアとツールについて簡単に説明してみます。

Xen仮想化の種類

Qubes は Xen ハイパーバイザーをベースにしており、プロセッサ リソース、メモリ、仮想マシンの管理機能を最小限に抑えています。デバイスに関するその他すべての作業は、Linux カーネルに基づいて dom0 に集中されます (dom0 の Qubes は Fedora ディストリビューションを使用します)。

Xen はいくつかの種類の仮想化をサポートしています (ここでは Intel アーキテクチャの例を示しますが、Xen は他の種類の仮想化をサポートしています)。

• 準仮想化 (PV) - ハードウェア サポートを使用しない仮想化モードで、コンテナ仮想化を彷彿とさせます。適応されたカーネルを備えたシステムに使用できます (dom0 はこのモードで動作します)。
• 完全仮想化 (HVM) - このモードでは、ハードウェア サポートがプロセッサ リソースに使用され、他のすべての機器は QEMU を使用してエミュレートされます。これは、さまざまなオペレーティング システムを実行するための最も普遍的な方法です。
• ハードウェアの準仮想化 (PVH - ParaVirtualized Hardware) - ハードウェアを操作するために、ゲスト システム カーネルがハイパーバイザーの機能 (共有メモリなど) に適合したドライバーを使用する場合に、ハードウェア サポートを使用する仮想化モードで、QEMU エミュレーションの必要がなくなります。 I/O パフォーマンスの向上。 4.11 以降の Linux カーネルは、このモードで動作できます。

Qubes 4.0 以降、セキュリティ上の理由から、準仮想化モードの使用は廃止され (完全仮想化を使用することで部分的に軽減される Intel アーキテクチャの既知の脆弱性を含む)、デフォルトで PVH モードが使用されます。

エミュレーション (HVM モード) を使用する場合、QEMU はスタブドメインと呼ばれる分離された VM で起動されるため、実装における潜在的なエラーが悪用されるリスクが軽減されます (QEMU プロジェクトには、互換性を含む多くのコードが含まれています)。
この例では、Windows ではこのモードを使用する必要があります。

サービス仮想マシン

Qubes セキュリティ アーキテクチャでは、ハイパーバイザーの重要な機能の XNUMX つは、PCI デバイスをゲスト環境に転送することです。ハードウェアの除外により、システムのホスト部分を外部攻撃から隔離できます。 Xen は PV および HVM モードでこれをサポートします。XNUMX 番目のケースでは、仮想化デバイスのハードウェア メモリ管理である IOMMU (Intel VT-d) のサポートが必要です。

これにより、いくつかのシステム仮想マシンが作成されます。

• sys-net: ネットワーク デバイスが転送され、他の VM (ファイアウォールや VPN クライアントの機能を実装する VM など) へのブリッジとして使用されます。
• sys-usb、USB およびその他の周辺デバイス コントローラーが転送されます。
• sys-firewall はデバイスを使用しませんが、接続された VM のファイアウォールとして機能します。

USB デバイスを操作するには、特に次の機能を提供するプロキシ サービスが使用されます。

• HID (ヒューマン インターフェイス デバイス) デバイス クラスの場合は、dom0 にコマンドを送信します。
• リムーバブル メディアの場合、デバイス ボリュームを他の VM (dom0 を除く) にリダイレクトします。
• USB デバイスに直接リダイレクトします (USBIP および統合ツールを使用)。

このような構成では、ネットワーク スタックまたは接続されたデバイスを介した攻撃が成功すると、システム全体ではなく、実行中のサービス VM のみが侵害される可能性があります。サービス VM を再起動すると、元の状態でロードされます。

VM統合ツール

仮想マシンのデスクトップを操作するには、ゲスト システムにアプリケーションをインストールする方法や、仮想化ツールを使用してビデオをエミュレートする方法など、いくつかの方法があります。ゲスト アプリケーションは、さまざまなユニバーサル リモート アクセス ツール (RDP、VNC、Spice など) にすることも、特定のハイパーバイザーに適合させることもできます (このようなツールは通常、ゲスト ユーティリティと呼ばれます)。ハイパーバイザーがゲスト システムの I/O をエミュレートし、Spice などの I/O を組み合わせるプロトコルを使用する機能を外部から提供する場合、混合オプションを使用することもできます。同時に、リモート アクセス ツールはネットワーク経由で作業するため、通常は画像を最適化しますが、これは画像の品質に良い影響を与えません。

Qubes は、VM 統合用の独自のツールを提供します。まず第一に、これはグラフィック サブシステムです。さまざまな VM のウィンドウが、独自のカラー フレームを使用して XNUMX つのデスクトップに表示されます。一般に、統合ツールはハイパーバイザーの機能、つまり共有メモリ (Xen 許可テーブル)、通知ツール (Xen イベント チャネル)、共有ストレージ xenstore、および vchan 通信プロトコルに基づいています。これらの助けを借りて、基本コンポーネント qrexec と qubes-rpc、およびアプリケーション サービス (オーディオまたは USB のリダイレクト、ファイルまたはクリップボードの内容の転送、コマンドの実行、アプリケーションの起動) が実装されます。 VM で利用可能なサービスを制限できるポリシーを設定できます。以下の図は、XNUMX つの VM の相互作用を初期化する手順の例です。

これにより、VM上での作業はネットワークを介さずに実行されるため、自律的なVMを最大限に活用して情報漏洩を防ぐことができます。たとえば、秘密キーが分離された VM で使用され、それを超えない場合、これは暗号化操作の分離 (PGP/SSH) が実装される方法です。

テンプレート、アプリケーション、ワンタイム VM

Qubes でのユーザーの作業はすべて仮想マシンで行われます。メインのホスト システムは、それらの制御と視覚化に使用されます。 OS は、テンプレートベースの仮想マシン (TemplateVM) の基本セットとともにインストールされます。このテンプレートは、Fedora または Debian ディストリビューションに基づく Linux VM であり、統合ツールがインストールおよび構成され、専用のシステム パーティションとユーザー パーティションが備えられています。ソフトウェアのインストールと更新は、必須のデジタル署名検証 (GnuPG) を使用して、設定されたリポジトリから標準のパッケージ マネージャー (dnf または apt) によって実行されます。このような VM の目的は、その VM に基づいて起動されるアプリケーション VM の信頼性を確保することです。

アプリケーション VM (AppVM) は起動時に、対応する VM テンプレートのシステム パーティションのスナップショットを使用し、完了時に変更を保存せずにこのスナップショットを削除します。ユーザーが必要とするデータは、ホームディレクトリにマウントされるアプリケーションVMごとに固有のユーザーパーティションに保存されます。

使い捨て VM (disposableVM) の使用は、セキュリティの観点から役立つ場合があります。このような VM は起動時にテンプレートに基づいて作成され、XNUMX つのアプリケーションを実行するという XNUMX つの目的で起動され、アプリケーションが閉じられた後に作業を完了します。使い捨て VM を使用すると、その内容が特定のアプリケーションの脆弱性の悪用につながる可能性のある不審なファイルを開くことができます。ワンタイム VM を実行する機能は、ファイル マネージャー (Nautilus) と電子メール クライアント (Thunderbird) に統合されています。

Windows VM を使用して、ユーザー プロファイルを別のセクションに移動することで、テンプレートとワンタイム VM を作成することもできます。私たちのバージョンでは、このようなテンプレートは、ユーザーが管理タスクやアプリケーションのインストールに使用します。テンプレートに基づいて、ネットワークへのアクセスが制限されている (標準の sys-firewall 機能) か、ネットワークへのアクセスがまったくない (仮想ネットワーク デバイスは作成されない) いくつかのアプリケーション VM が作成されます。テンプレートにインストールされているすべての変更とアプリケーションは、これらの VM で使用できるようになり、ブックマーク プログラムが導入された場合でも、ネットワークにアクセスして侵害されることはありません。

Windows のために戦う

上記の機能は Qubes の基礎であり、非常に安定して動作しますが、問題は Windows から始まります。 Windows を統合するには、一連のゲスト ツール Qubes Windows Tools (QWT) を使用する必要があります。これには、Xen と連携するためのドライバー、qvideo ドライバー、および情報交換 (ファイル転送、クリップボード) のためのユーティリティのセットが含まれています。インストールと構成のプロセスはプロジェクト Web サイトに詳細に文書化されているため、アプリケーションのエクスペリエンスを共有します。

主な問題は、基本的に、開発されたツールのサポートが欠如していることです。主要開発者 (QWT) が不在のようで、Windows 統合プロジェクトは主任開発者を待っています。したがって、まず第一に、そのパフォーマンスを評価し、必要に応じて独自にサポートする可能性について理解を形成する必要がありました。開発とデバッグが最も難しいのはグラフィックス ドライバーです。グラフィックス ドライバーは、ビデオ アダプターとディスプレイをエミュレートして共有メモリにイメージを生成し、デスクトップ全体またはアプリケーション ウィンドウをホスト システム ウィンドウに直接表示できるようにします。ドライバーの動作を分析する際、Linux 環境でのアセンブリ用にコードを調整し、XNUMX つの Windows ゲスト システム間のデバッグ スキームを考案しました。クロスビルドの段階で、主にユーティリティの「サイレント」インストールという点で作業を簡素化するいくつかの変更を加えました。また、VM で長時間作業する際の煩わしいパフォーマンスの低下も排除しました。作業結果は別記事で紹介しました リポジトリしたがって、長くは続かない 感動的な Qubes 開発者のリーダー。

ゲスト システムの安定性の点で最も重要な段階は Windows の起動です。ここでは見慣れたブルー スクリーンが表示されます (または表示すらされません)。特定されたエラーのほとんどについては、Xen ブロック デバイス ドライバーの削除、VM メモリ バランシングの無効化、ネットワーク設定の修正、コア数の最小化など、さまざまな回避策がありました。当社のゲスト ツール ビルドは、完全に更新された Windows 7 および Windows 10 (qvideo を除く) にインストールされ、実行されます。

実環境から仮想環境に移行する場合、プレインストールされた OEM バージョンを使用すると、Windows のライセンス認証で問題が発生します。このようなシステムでは、デバイスの UEFI で指定されたライセンスに基づいてアクティベーションが使用されます。アクティベーションを正しく処理するには、ホスト システムの ACPI セクション全体 (SLIC テーブル) の XNUMX つをゲスト システムに変換し、残りをわずかに編集して製造元を登録する必要があります。 Xen では、主要なテーブルを変更せずに、追加のテーブルの ACPI コンテンツをカスタマイズできます。 Qubes 用に調整された同様の OpenXT プロジェクトのパッチが解決に役立ちました。この修正は私たちだけでなく役立つと思われ、メインの Qubes リポジトリと Libvirt ライブラリに翻訳されました。

Windows 統合ツールの明らかな欠点には、GPU のハードウェア サポートがないため、オーディオ、USB デバイスがサポートされていないこと、メディアの操作が複雑であることが含まれます。ただし、上記はオフィス文書を操作するための VM の使用を妨げるものではなく、特定の企業アプリケーションの起動を妨げるものでもありません。

Windows VM テンプレートの作成後に、ネットワークなしまたはネットワークが制限された動作モードに切り替える要件は、アプリケーション VM の適切な構成を作成することで満たされ、リムーバブル メディアを選択的に接続する可能性も、接続時に標準の OS ツールによって解決されました。 、それらはシステム VM sys-usb で利用可能であり、そこから必要な VM に「転送」できます。ユーザーのデスクトップは次のようになります。

システムの最終バージョンは (このような包括的なソリューションが許す限り) ユーザーに積極的に受け入れられ、システムの標準ツールにより、VPN 経由でアクセスできるユーザーのモバイル ワークステーションにアプリケーションを拡張することが可能になりました。

代わりに、結論の

一般に、仮想化により、サポートを受けずに放置された Windows システムを使用するリスクを軽減できます。仮想化により、新しいハードウェアとの互換性が強制されず、ネットワークまたは接続されたデバイスを介したシステムへのアクセスを除外または制御でき、次のことが可能になります。ワンタイム起動環境を実装します。

Qubes OS は、仮想化による分離の考えに基づいて、セキュリティのためのこれらのメカニズムやその他のメカニズムを活用するのに役立ちます。外部から見ると、多くの人は Qubes を主に匿名性への欲求として見ていますが、プロジェクト、インフラストラクチャ、およびそれらにアクセスするための秘密を頻繁にやりくりするエンジニアにとっても、セキュリティ研究者にとっても便利なシステムです。アプリケーション、データの分離、およびそれらの相互作用の形式化は、脅威分析とセキュリティ システム設計の最初のステップです。この分離により、情報が構造化され、急ぎや疲労などの人的要因によるエラーの可能性が軽減されます。

現在、開発において主に重点を置いているのは、Linux 環境の機能を拡張することです。バージョン 4.1 はリリースに向けて準備中です。これは Fedora 31 をベースにしており、主要コンポーネントである Xen と Libvirt の最新バージョンが含まれています。 Qubes が情報セキュリティの専門家によって作成されており、新しい脅威やエラーが特定された場合には、常に迅速にアップデートをリリースしていることは注目に値します。

後書き

私たちが開発中の実験機能の 4.1 つでは、Intel GVT-g テクノロジーに基づいて GPU へのゲスト アクセスをサポートする VM を作成できます。これにより、グラフィックス アダプターの機能を使用して、システムの範囲を大幅に拡張できます。執筆時点では、この機能は Qubes XNUMX のテスト ビルドで動作し、次の場所で利用できます。 githubの.

出所： habr.com