Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

仮想化セキュリティーガイド

Red Hat Enterprise Linux 7

仮想化環境のセキュリティー保護

Jiri Herrmann

Red Hat Customer Content Services

Yehuda Zimmerman

Red Hat Customer Content Services

Scott Radvan

Red Hat Customer Content Services

Tahlia Richardson

Red Hat Customer Content Services

Thanks go to the following people for enabling the creation of this guide:

Paul Moore

Red Hat エンジニアリング

Kurt Seifried

Red Hat エンジニアリング

David Jorm

Red Hat エンジニアリング

概要

本ガイドは、Red Hat が提供する仮想化セキュリティーテクノロジーについての概要を説明します。仮想化環境内のホスト、ゲスト、および共有インフラストラクチャー/リソースのセキュリティーを保護するための推奨事項を提供します。

第1章 はじめに

1.1. 仮想化環境と非仮想化環境

仮想化環境は、攻撃者にとって以前は価値がなかった新たな攻撃ベクトルの発見と既存のエクスプロイトの洗練の両方の機会を与えます。このため、仮想マシンを作成し、これを維持する際には、物理ホストとそのホストで実行されるゲストの両方のセキュリティーを確保するための対策を講じることが重要となります。
非仮想化環境

非仮想化環境では、ホストは物理的に相互分離しており、各ホストには Web サーバーや DNS サーバーなどのサービスで構成される自己完結型の環境があります。これらのサービスは、独自のユーザースペース、ホストカーネル、物理ホストと直接通信して、ネットワークに直接サービスを提供します。

非仮想化環境

図1.1 非仮想化環境

仮想化環境

仮想化環境では、複数のオペレーティングシステムを (ゲストの仮想マシンとして) 単一のホストカーネルおよび物理ホストに格納できます。

仮想化環境

図1.2 仮想化環境

サービスが仮想化されていない場合は、マシンは物理的に分離されています。したがって、エクスプロイトは影響を受けたマシンに抑えられます。ただし、ネットワーク攻撃は例外となります。仮想化環境内でサービスがグループ化されると、システムの脆弱性が高まります。ハイパーバイザーのセキュリティーに不備がある場合、ゲストインスタンスによるエクスプロイトを受ける可能性があり、そのゲストはホストのみならず、そのホストで実行している他のゲストも攻撃できるようになる可能性があります。

1.2. 仮想化セキュリティーが重要である理由

インフラストラクチャーに仮想化をデプロイすると、数多くのメリットがもたらされますが、新たなリスクが生じる可能性もあります。仮想化のリソースとサービスのデプロイにあたっては以下のようなセキュリティーに関する考慮事項を検討した上でデプロイを行う必要があります。
  • ホストおよびハイパーバイザーは第一のターゲットであり、ゲストとデータの単一障害点となることが多くあります。
  • 仮想マシンは望ましくない方法で相互干渉する場合があります。これを防ぐためのアクセス制御が導入されていないとすると、悪意のあるゲストが脆弱なハイパーバイザーをバイパスし、他のゲストのストレージなど、ホストシステム上の他のリソースに直接アクセスする可能性があります。
  • 仮想化システムを迅速にデプロイすると、十分なパッチ、モニタリング、メンテナンスなどのリソース管理の必要性が増大するため、リソースとサービスのトラッキングおよび維持管理が難しくなる場合があります。
  • ストレージなどのリソースが複数のマシンに散在し、それらのマシンに依存している場合があります。このような場合には環境が過度に複雑化してしまい、システムの管理とメンテナンスが不十分となる可能性があります。
  • 仮想化によって、環境内に存在する従来のセキュリティーリスクは排除されません。仮想化レイヤーのみでなく、ソリューションスタック全体のセキュリティーを保護する必要があります。
本ガイドは、仮想化インフラストラクチャーのセキュリティー保護に役立つ Red Hat Enterprise Linux の仮想化推奨プラクティスを紹介し、お客様のセキュリティーリスクを軽減することを目的としています。

第2章 ホストのセキュリティー

Red Hat Enterprise Linux システムは、仮想化テクノロジーをデプロイする際、ホストは、物理デバイス、ストレージ、ネットワークへのアクセスに加え、全仮想化ゲスト自体を管理および制御します。ホストシステムのセキュリティーが侵害されると、ホストシステムのみでなくゲストとそのデータまでもが攻撃を受ける可能性があります。
Red Hat Enterprise Linux ホストシステムのセキュリティー保護は、セキュアな仮想化プラットフォームの確立に向けた第一歩です。

2.1. ホスト物理マシンのセキュリティー保護

Red Hat Enterprise Linux ホストのパフォーマンスを強化するには、安全性や信頼性を確保することを支援する次のようなタスクやヒントが役立ちます。
  • SELinux がインストール用に適切に構成されており、Enforcing モードで動作していることを確認します。
    # setenforce 1
    これは、適正なセキュリティーのプラクティスである上、sVirt が提供する高度な仮想化セキュリティー機能は SELinux に依存しています。SELinux と sVirt に関する詳細は「4章sVirt」を参照してください。
  • すべての不必要なサービスを削除するか、または無効にします (AutoFSNFSFTPHTTPNIStelnetdsendmail など)。
  • サーバーでのプラットフォーム管理に最低限必要なユーザーアカウントだけを追加し、不要なユーザーアカウントを削除します。システムへの直接のアクセスは、システムの管理を行う必要がある人に制限してください。共有の root アクセスを無効にして、代わりに sudo などのツールを使用して、管理ロールに基づいて管理者に特権アクセスを付与することを検討してください。
  • ホストでは不要なアプリケーションは実行しないようにしてください。ホストでアプリケーションを実行すると仮想マシンのパフォーマンスに影響を与えるため、その影響がサーバーの安定性におよぶ可能性があります。サーバーをクラッシュさせる可能性のあるアプリケーションは、サーバー上のすべての仮想マシンをダウンさせてしまう原因ともなります。また、脆弱なアプリケーションは、ホストの攻撃のための進路となります。
  • 仮想マシンのインストールおよびイメージには集中管理できる場所を使用します。仮想マシンのイメージは /var/lib/libvirt/images/ に格納してください。仮想マシンのイメージをこれ以外のディレクトリーに格納する場合は、そのディレクトリーを SELinux ポリシーに追加し、インストールを開始する前にラベルの再設定を必ず行ってください。集中管理ができる共有可能なネットワークストレージの使用を強くお勧めします。
  • ゲストシステムの使用と管理のサポートに必要なサービスのみを実行します。ファイルサービスや印刷サービスなどのサービスを追加で提供する必要がある場合には、それらのサービスを Red Hat Enterprise Linux ゲストで実行することを検討してください。
  • ホストシステムで 監査が有効になり、libvirt が監査レコードを生成するように設定されていることを確認します。監査が有効になると、libvirt はゲストの設定変更および起動/停止イベントの監査レコードを生成します。これは、ゲストの状態をトラッキングするように役立ちます。また、libvirt の監査イベントは、標準の auvirt ユーティリティーを使用して表示できます。詳細は、man auvirt コマンドを使用します。
  • システムのリモート管理はすべてセキュアなネットワークチャネルでのみ実行されるようにしてください。SSH のようなユーティリティーや、TLS または SSL などのネットワークプロトコルは認証とデータ暗号化の両方を提供し、承認済みの管理者のみがシステムをリモートで管理できるようにするのに役立ちます。
  • ご使用のインストールに応じてファイアウォールが適切に設定されており、システムの起動時にアクティブ化されることを確認します。システムの使用および管理に必要なネットワークポートのみを許可する必要があります。
  • ディスク全体またはブロックデバイス (例: /dev/sdb) への直接のアクセスをゲストに許可するのは控えて、代わりにゲストストレージにはパーティション (例: /dev/sdb1) や LVM ボリュームを使用します。
  • SR-IOV が仮想マシンで利用不可能な場合に USB デバイス、物理ファンクション、または物理デバイスをアタッチすると、デバイスへのアクセスが提供され、これでファームウェアを上書きすることができます。これは、悪意のあるコードを使用して攻撃者がデバイスのファームウェアを上書きし、仮想マシン間でデバイスを移動する際やホストの起動時に問題を生じさせるという潜在的なセキュリティー上の問題を引き起こします。
    該当する SR-IOV 仮想機能デバイスの割り当てを使用することが推奨されます。

注記

ホストシステムでのセキュリティーのヒントおよび使用方法は、『Red Hat Enterprise Linux セキュリティーガイド』を参照してください。

2.2. クライアントアクセス制御

libvirt のクライアントアクセス制御フレームワークでは、システム管理者は複数のクライアントユーザー、管理オブジェクト、および API 操作に対する細かい権限のルールを設定できます。これにより、クライアントの接続を最小限の特権セットに制限できます。
デフォルトの設定では、libvirtd デーモンは、アクセス制御のレベルが 3つあります。
  1. すべての接続は認証されていない状態で開始します。ここで許可される唯一の API 操作は、認証を完了するために必要なものです。
  2. 認証が成功すると、接続がすべての libvirt API コールへの無制限なフルアクセスがあるか、「読み取り専用」の操作に限定されます。これは、クライアント接続が開始したソケットによって異なります。
  3. アクセス制御フレームワークには、認証された接続は、管理者により定義されるきめ細かなアクセス許可のルールを持つことができます。
libvirt のすべての API 呼び出しには、使用されるオブジェクトに対して検証される一連のアクセス権があります。さらに、特定のフラグが API 呼び出しに設定されているかについてアクセス権のチェックが行われます。API 呼び出しに渡されるオブジェクトのチェックのほかにも、一部のメソッドは結果をフィルタリングします。

2.2.1. アクセス制御ドライバー

アクセス制御フレームワークは、今後追加される任意のアクセス制御技術との統合を可能にするためにプラグ可能なシステムとして設計されています。デフォルトでは、ドライバーは使用されません。そのため、アクセス制御のチェックは実行されません。現在、libvirt は polkit を実際のアクセス制御ドライバーとして使用するためのサポートを提供します。polkit アクセス制御ドライバーの使用方法は、設定ドキュメント を参照してください。
アクセス制御ドライバーは、/etc/libvirt/libvirtd.conf パラメーターを使用して libvirtd.conf 設定ファイルで設定されます。このパラメーターは、さまざまなアクセス制御ドライバー名を受け入れます。複数のアクセス制御ドライバーが必要とされる場合は、すべてのアクセス制御ドライバーのアクセスが付与されるようにそれらが処理される必要があります。「polkit」をドライバーとして有効にするには、augtool コマンドを実行します。
# augtool -s set '/files/etc/libvirt/libvirtd.conf/access_drivers[1]' polkit
ドライバーをデフォルト (アクセス制御なし) に戻すには、以下のコマンドを入力します。
# augtool -s rm /files/etc/libvirt/libvirtd.conf/access_drivers
libvirtd.conf への変更を適用すると、libvirtd サービスを再起動します。
# systemctl restart libvirtd.service

2.2.2. オブジェクトおよびアクセス権

libvirt は、アクセス制御を、その API の主なオブジェクトタイプのすべてに適用します。それぞれのオブジェクトタイプには、それぞれ一連の権限が定義されます。特定の API 呼び出しについてチェックされる権限を判別するには、該当 API の API 参照マニュアルを参照してください。オブジェクトと権限の詳細の一覧は、libvirt.org を参照してください。

2.2.3. ブロックデバイスをゲストに追加する際のセキュリティー上の懸念事項

  • ホストの物理マシンで fstab ファイル、initrd ファイル、またはカーネルコマンドラインでファイルシステムを特定する場合は、ファイルシステムのラベルを使用でください。ゲストの仮想マシンは、ホストの物理マシンに属するファイルシステムのラベルを潜在的に自身のブロックデバイスストレージに書き込むことができるため、それを行うには、ゲストの仮想マシンに、パーティションまたは LVM ボリュームに対する書き込みアクセスがある場合のセキュリティーリスクが発生します。ホストの物理マシンの再起動時に、ホストの物理マシンが、ホストの物理マシンが、このゲストの仮想マシンのディスクをシステムディスクとして誤って使用してしまう可能性があり、ホストの物理マシンシステムが危険にさらされる可能性があります。
    /etc/fstab ファイル、/dev/initrd ファイル、またはカーネルコマンドラインでデバイスを識別する場合は、デバイスの UUID を使用することが推奨されます。
  • ゲスト仮想マシンは、ディスク全域、またはブロックデバイス全域 (例: /dev/sdb) に書き込みアクセスを持つべきではありません。ブロックデバイス全域にアクセスを持つゲスト仮想マシンはボリュームラベルを修正できる場合があり、これがホスト物理マシンシステムの攻撃に使用される可能性があります。パーティション (例: /dev/sdb1) または LVM ボリュームを使用して、この問題を回避してください。LVM 管理および設定の例は、「CLI コマンドでの LVM 管理」または「LVM 設定の例」を参照してください。
    /dev/sdb1、または RAW ディスク (例: /dev/sdb) などのパーティションへの RAW アクセスを使用する場合は、global_filter 設定を使用して、安全なディスクのみをスキャンできるように LVM を設定する必要があります。global_filter コマンドを使用しは LVM 設定スクリプトの例は、『論理ボリュームマネージャーの管理』を参照してください。

第3章 ゲストのセキュリティー

3.1. ゲストのセキュリティーが重要である理由

ホストシステムのセキュリティーは、そのホスト上で実行されているゲストを確実にセキュリティー保護するために極めて重要となりますが、ホストのセキュリティーによって個別のゲストマシンの適切なセキュリティー保護の必要性がなくなる訳ではありません。システムを仮想化ゲストとして実行する場合、従来の非仮想化システムに関連するセキュリティー上のリスクはすべて依然として存在します。ゲストシステムのセキュリティーが侵害されると、ビジネスデータや顧客の機密情報など、ゲストシステムにアクセス可能なリソースはいずれも攻撃を受けやすくなる可能性があります。

3.3. Kernel Adress Space Layout Randomization

Red Hat Enterprise Linux 7.5 以降では、KVM ゲスト仮想マシンの Kernel Address Space Randomization (KASLR) 機能が含まれています。KASLR は、カーネルイメージを解凍する物理アドレスおよび仮想アドレスをランダム化できるため、カーネルオブジェクトの位置に基づいて、ゲストのセキュリティー攻撃を防ぎます。
KASLR はデフォルトで有効にされますが、ゲストのカーネルコマンドラインに nokaslr 文字列を追加することで、特定のゲストで無効にできます。ゲストの起動オプションを編集するには、次のコマンドを使用します。guestname はゲストの名前です。
# virt-edit -d guestname /etc/default/grub
その後、たとえば、GRUB_CMDLINE_LINUX を変更します。
GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet nokaslr"

重要

KASLR で有効になっているゲストから作成したゲストのダンプファイルは、crash ユーティリティでは読み込みできません。これを修正するには、ゲストの XML 設定ファイルの <features> セクションに <vmcoreinfo/> 要素を追加します。
宛先のホストが <vmcoreinfo/> をサポートしない OS を使用している場合は、<vmcoreinfo/> を使用したゲストの 移行 に失敗します。これには、Red Hat Enterprise Linux 7.4 以前のバージョンと、Red Hat Enterprise Linux 6.9 以前のバージョンが該当します。

第4章 sVirt

4.1. はじめに

KVM 下の仮想マシンは Linux プロセスとして実装されているため、KVM は標準の Linux セキュリティーモデルを活用して分離とリソースの制御を行います。Linux カーネルには、SELinux (Security-Enhanced Linux) が搭載されており、柔軟性の高いカスタマイズ可能なセキュリティーポリシーを通して、強制アクセス制御 (MAC)、マルチレベルセキュリティー (MLS)、およびマルチカテゴリーセキュリティー (MCS) を追加します。SELinux は、Linux カーネルで実行しているプロセス (仮想マシンプロセスを含む) を対象とした、リソースの厳重な分離および隔離を行います。sVirt プロジェクトは SELinux を基盤として、仮想マシンの分離と制御された共有をさらに促進します。たとえば、粒度の細かいアクセス権を適用して仮想マシンをグループ化し、リソースを共有できます。
セキュリティーの観点からすると、ハイパーバイザーは攻撃者の格好の的です。これは、ハイパーバイザーがセキュリティー侵害を受けると、そのホストシステムで実行している仮想マシンのセキュリティーもすべて被害を受けることになる可能性があるためです。仮想化テクノロジーに SELinux を組み込むと、ホストシステムや他の仮想マシンへのアクセスを試みる悪意のある仮想マシンに対するハイパーバイザーのセキュリティーを強化するのに役立ちます。
以下の図は、ゲストを分離することで、セキュリティー侵害されたハイパーバイザー (またはゲスト) がさらなる攻撃を加えたり、別のインスタンスにまで被害を拡げたりする能力を抑える仕組みを示しています。
Image shows that separate virtual machines are isolated and an attack path coming from one guest can be contained by SELinux.

図4.1 SELinux によって分離される攻撃パス

注記

SELinux の詳細については、『Red Hat Enterprise Linux SELinux ユーザーおよび管理者のガイド』を参照してください。

4.2. SELinux と強制アクセス制御 (MAC)

Security-Enhanced Linux (SELinux) は、Linux カーネルにおける MAC の実装です。標準の任意アクセス制御 (DAC) がチェックされたあとに、許可された操作をチェックします。SELinux は、実行中のプロセスとそれらの動作 (例: ファイルシステムオブジェクトへのアクセスを試みるなど) に対して、ユーザーがカスタマイズ可能なセキュリティーポリシーを適用することができます。Red Hat Enterprise Linux では SELinux がデフォルトで有効化されており、アプリケーションやシステムサービス (例: ハイパーバイザー) の脆弱性の悪用によって生じる可能性のある潜在的被害の範囲を制限します。
sVirt は、仮想化管理用の抽象化レイヤーである libvirt と一体化して、仮想マシン用の MAC フレームワークを提供します。このアーキテクチャーは、libvirt によってサポートされている全仮想化プラットフォームと、sVirt によりサポートされている全 MAC 実装が相互運用可能となります。

4.3. sVirt の設定

SELinux ブール値は、オン/オフ切り替えが可能な変数で、機能やその他の特殊条件を迅速に有効化/無効化することができます。ブール値は、一時的な変更の場合は setsebool boolean_name {on|off}、再起動時に変更を永続化する場合は setsebool -P boolean_name {on|off} のいずれかを実行することによって切り替えることができます。
以下の表は、libvirt で始動された場合に KVM に影響する SELinux ブール値を示しています。これらのブール値 (オンまたはオフ) の現在の状態は、コマンド getsebool -a|grep virt を実行することにより確認できます。

表4.1 KVM SELinux のブール値

SELinux のブール値説明
staff_use_svirtstaff ユーザーによる sVirt ドメイン作成、およびそのドメインへの移行を有効にします。
unprivuser_use_svirt非特権ユーザーによる sVirt ドメイン作成、およびそのドメインへの移行を有効にします。
virt_sandbox_use_auditサンドボックスコンテナーによる監査メッセージの送信を有効にします。
virt_sandbox_use_netlinkサンドボックスコンテナーによるネットリンクシステム呼び出しの使用を有効にします。
virt_sandbox_use_sys_adminサンドボックスコンテナーによる sys_admin システム呼び出し (mount 等) の使用を有効にします。
virt_transition_userdomainユーザードメインとしての仮想プロセスの実行を有効にします。
virt_use_commvirt によるシリアルおよびパラレル通信ポートの使用を有効にします。
virt_use_execmem制限された仮想ゲストによる実行可能メモリーおよび実行可能スタックの使用を有効にします。
virt_use_fusefsvirt による FUSE マウントされたファイルの読み取りを有効にします。
virt_use_nfsvirt による NFS マウントされたファイルの管理を有効にします。
virt_use_rawipvirt による rawip ソケットとの通信を有効にします。
virt_use_sambavirt による CIFS マウントされたファイルの管理を有効にします。
virt_use_sanlock制限された仮想ゲストによる sanlock との通信を有効にします。
virt_use_usbvirt による USB デバイスの使用を有効にします。
virt_use_xserver仮想マシンによる X Window System との通信を有効にします。

注記

SELinux ブール値の詳細については、『Red Hat Enterprise Linux SELinux ユーザーおよび管理者のガイド』を参照してください。

4.4. sVirt のラベル付け

SELinux の保護下にある他のサービスと同様に、sVirt はプロセスベースのメカニズム、ラベル、制限を使用してセキュリティーを強化し、ゲストインスタンスを制御します。ラベルは、現在実行中の仮想マシンに基づいて、システムのリソースに自動的に適用されます (動的) が、管理者が手動で指定して (静的)、特別な要件がある場合でも対応することができます。
ゲストの sVirt ラベルを編集するには、virsh edit guest_name コマンドを使用して、以下のセクションに記載される <seclabel> 要素を追加または編集します。<seclabel> は、ゲスト全体の root 要素として使用できます。または、特定のデバイスで特定の sVirt ラベルを選択するために、<source> 要素のサブ要素として指定できます。
<seclabel> 要素の総合的な情報は、libvirt のアップストリームのドキュメントを参照してください。

4.4.1. sVirt ラベルのタイプ

以下の表には、仮想マシンのプロセス、イメージファイル、共有コンテンツなどのリソースに割り当てることができる、異なる sVirt ラベルについての説明をまとめています。

表4.2 sVirt ラベル

タイプSELinux コンテキスト説明/効果
仮想マシンプロセスsystem_u:system_r:svirt_t:MCS1MCS1 は無作為に選択されたフィールドです。現在は、約 500,000 のラベルがサポートされています。
仮想マシンのイメージsystem_u:object_r:svirt_image_t:MCS1これらのイメージファイルやデバイスの読み取り/書き込みができるのは、同じ MCS1 フィールドが付いた svirt_t プロセスのみです。
仮想マシンの共有読み取り/書き込みコンテンツsystem_u:object_r:svirt_image_t:s0svirt_t プロセスはすべて、svirt_image_t:s0 のファイルおよびデバイスに書き込むことができます。
仮想マシンの共有読み取り専用コンテンツsystem_u:object_r:svirt_content_t:s0svirt_t プロセスはすべて、このラベルがついたファイル/デバイスを読み取ることができます。
仮想マシンのイメージsystem_u:object_r:virt_content_t:s0イメージが存在する場合に使用されるシステムのデフォルトラベル。svirt_t 仮想プロセスは、このラベルの付いたファイル/デバイスの読み取りはできません。

4.4.2. 動的設定

動的ラベル設定は、sVirt を SELinux と併用する場合のデフォルトのラベルオプションです。以下の例は、動的ラベリングを示しています。
# ps -eZ | grep qemu-kvm

system_u:system_r:svirt_t:s0:c87,c520 27950 ?  00:00:17 qemu-kvm
この例では、qemu-kvm プロセスに system_u:system_r:svirt_t:s0 のベースラベルが付いています。libvirt システムは、このプロセス用に一意の MCS ラベル c87,c520 を生成しています。ベースラベルと MCS ラベルを組み合わせることにより、そのプロセス用の完全なセキュリティーラベルが形成されます。同様に、libvirt は同じ MCS ラベルとベースラベルを使用してイメージラベルを形成します。このイメージラベルは次に、ディスクイメージやディスクデバイス、PCI デバイス、USB デバイス、kernel/initrd ファイルなど、仮想マシンがアクセスする必要のある全ホストファイルに自動的に適用されます。各プロセスは、異なるラベルを使用して、他の仮想マシンから分離されます。
以下の例は、/var/lib/libvirt/images 内のゲストディスクイメージに適用された、仮想マシンの一意のセキュリティーラベル (この場合は、対応する MCS ラベルが c87,c520) を示しています。
# ls -lZ /var/lib/libvirt/images/*

  system_u:object_r:svirt_image_t:s0:c87,c520   image1
以下の例は、ゲストの XML 設定内の動的ラベルを示しています。
<seclabel type='dynamic' model='selinux' relabel='yes'>
  <label>system_u:system_r:svirt_t:s0:c87,c520</label>
  <imagelabel>system_u:object_r:svirt_image_t:s0:c87,c520</imagelabel>
</seclabel>

4.4.3. ベースラベルを使用した動的設定

デフォルトのダイナミックモードのベースセキュリティーラベルを上書きするには、以下の例に示したように、XML ゲスト設定内の <baselabel> オプションを手動で設定することができます。
<seclabel type='dynamic' model='selinux' relabel='yes'>
  <baselabel>system_u:system_r:svirt_custom_t:s0</baselabel>
  <label>system_u:system_r:svirt_custom_t:s0:c87,c520</label>
  <imagelabel>system_u:object_r:svirt_image_t:s0:c87,c520</imagelabel>
</seclabel>

4.4.4. 動的リソースラベルを使用した静的設定

一部のアプリケーションは、セキュリティーラベルの生成を完全に制御する必要がありますが、リソースのラベル付けは依然として libvirt が行う必要があります。以下のゲスト XML 設定は、動的リソースラベルを使用した静的設定の例を示しています。
<seclabel type='static' model='selinux' relabel='yes'>
  <label>system_u:system_r:svirt_custom_t:s0:c87,c520</label>
</seclabel>

4.4.5. リソースラベルを使用しない静的設定

MLS (マルチレベルセキュリティー) または厳重に管理された環境で主に使用される、リソース再ラベルを使用しない静的設定が可能です。静的ラベルにより管理者は、仮想マシン用に MCS/MLS フィールドなどの特定のラベルを選択できます。静的なラベルが付いた仮想マシンを実行する管理者は、イメージファイルに正しいラベルを設定する責任を担います。仮想マシンは常にそのラベルで起動し、sVirt システムは静的なラベルの付いた仮想マシンのコンテンツは決して変更しません。以下のゲスト XML 設定は、このシナリオの例を示しています。
<seclabel type='static' model='selinux' relabel='no'>
  <label>system_u:system_r:svirt_custom_t:s0:c87,c520</label>
</seclabel>

4.4.6. sVirt のラベル付けおよび NFS

NFSv4.1 ファイルシステムまたは NFSv4.2 ファイルシステムに sVirt ラベリングを使用する場合は、ゲストの共有をエクスポートする NFS ディレクトリーの root で、virt_var_lib_t への SELinux のコンテキストを変更する必要があります。たとえば、/exports/nfs/ ディレクトリーをエクスポートする場合は、以下のコマンドを実行します。
# semanage fcontext -a -t virt_var_lib_t '/exports/nfs/'
# restorecon -Rv /exports/nfs/
さらに、libvirt が、NFS ボリュームにおけるゲストの仮想マシンに sVirt ラベルを動的に生成し、シングルホスト内でラベルの一意性を保証するだけです。これは、複数ホスト間で多数のゲストが NFS ボリュームを共有する場合、重複したラベルが発生する可能性があり、それにより潜在的な脆弱性が作成される場合があることを意味します。
この問題を回避するには、次のいずれかを実行します。
  • 各仮想化ホストに異なる NFS ボリュームを使用してください。また、ゲストの実行 を実行すると、--migrate-disks オプションおよび --copy-storage-all オプションを使用してゲストストレージをコピーします。
  • virt-install コマンドでゲストを新規作成した場合は、以下のコマンドでゲストの静的ラベルを設定します。
    • --security オプションの使用。以下に例を示します。
      # virt-install --name guest1-rhel7 --memory 2048 --vcpus 2 --disk size=8 --cdrom /home/username/Downloads/rhel-workstation-7.4-x86_64-dvd.iso --os-variant rhel7 --security model=selinux,label='system_u:object_r:svirt_image_t:s0:c100,c200'
      これは、ゲスト上のすべてのディスクのセキュリティラベルを設定します。
    • seclabel パラメーターで --disk オプションを使用。以下に例を示します。
      # virt-install --name guest1-rhel7 --memory 2048 --vcpus 2 --disk /path/to/disk.img,seclabel.model=selinux,seclabel.label='system_u:object_r:svirt_image_t:s0:c100,c200' --cdrom /home/username/Downloads/rhel-workstation-7.4-x86_64-dvd.iso --os-variant rhel7
      これは、指定したディスクに対してのみ、セキュリティーラベルを設定します。

第5章 仮想化環境におけるネットワークセキュリティー

5.1. ネットワークセキュリティーの概要

大半の状況では、ネットワークはシステム、アプリケーション、管理インターフェースへの唯一のアクセス方法です。ネットワークは、仮想化システムおよびそれらのシステムでホストされているアプリケーションの可用性の管理において極めて重要な役割を果たすので、仮想化システムとデータをやり取りするネットワークチャネルをセキュアな状態に確保することは非常に重要です。
ネットワークのセキュリティー保護により、管理者は機密データのアクセスを制御して、情報の漏えいや改ざんから保護することができます。

付録A 追加情報

A.1. SELinux および sVirt

SELinux および sVirt に関する詳細情報:

A.2. 仮想化セキュリティー

仮想化セキュリティーに関する追加情報

付録B 改訂履歴

改訂履歴
改訂 1.0-22Thu May 23 2019Jiri Herrmann
7.7 ベータ版公開用バージョン
改訂 1.0-21Thu Oct 25 2018Jiri Herrmann
7.6 GA 公開用バージョン
改訂 1.0-21Thu Aug 14 2018Jiri Herrmann
7.6 ベータ版公開用バージョン
改訂 1.0-20Thu Apr 5 2018Jiri Herrmann
7.5 GA 公開用バージョン
改訂 1.0-18Thu Jul 27 2017Jiri Herrmann
7.4 GA 公開用バージョン
改訂 1.0-15Mon Oct 17 2016Jiri Herrmann
7.3 GA 公開用バージョン
改訂 1.0-9Thu Oct 08 2015Jiri Herrmann
改訂履歴の整理
改訂 1.0-8Wed Feb 18 2015Scott Radvan
7.1 GA リリース用バージョン

法律上の通知

Copyright © 2019 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.