MACドメイン

Xenでは仮想マシンモニタ内部でのドメイン間通信を制御することで、すべての仮想資源に対するアクセスを制御することができる。これは、Xenにおける仮想資源へのアクセスがドメイン0と呼ばれる特権を持ったVMを介して行われるためである。

例えば各VMが仮想ディスクにアクセスする場合には、ドメイン間通信を使ってドメイン0と通信し、ドメイン0が物理ディスクにアクセスする。その結果は、ドメイン間通信を行ってアクセス要求を出したVMに返される。

このように複数のVMからの仮想資源へのアクセスはドメイン0で物理資源へと振り分けられる。そのため、ドメイン0は仮想資源にアクセスしようとしているVMが十分な権限を持っていることを保証する必要がある。sHypeでは「ドメイン0内のOS上でも仮想資源を分離する」「VMによる仮想資源へのアクセスを制御する」の2つの機能によりこれを保証している。

sHypeではドメイン0のようなVMのことを「MACドメイン」と呼び、SELinuxなどのセキュアOSと連携して強制アクセス制御を実現している（図3）。MACドメインではsHypeが管理しているTEタイプをSELinuxなどのTEタイプに変換して扱う。

さらに、MACドメイン内でType Enforcementポリシーを実現するには、どのVMが仮想資源にアクセスしようとしているかを知る必要がある。そのために、sHypeではMACドメインが要求元のVMのTEタイプを知るためのインターフェースを用意している。要求元のVMのTEタイプと仮想資源のTEタイプが一致すれば、MACドメインはアクセスを許可する。

複数の仮想マシンモニタの強制アクセス制御「Shamon」

sHypeは1台のマシン上の仮想マシンモニタで強制アクセス制御を行うが、これを複数のマシン上の仮想マシンモニタに拡張した「Shamon」と呼ばれるアーキテクチャも提案されている。Shamonは複数のマシン上のVMに仮想的に1つのリファレンスモニタを提供し、統一的に強制アクセス制御を行えるようにしている。

Shamonでは各マシン上で動いているMACドメイン（ドメイン0）の間でIPsecトンネルを構築することで、マシンをまたがるVM間での情報流の制御を行う。このIPsecトンネルを確立する際に、要求元のVMにつけられたTEタイプとIPsecポリシーを比較して、通信を許可するかどうかを判断する。

Xen Security Module（XSM）

今回の最後に、より一般的なセキュリティフレームワークを目指して開発されている「Xen Security Module（XSM）」を紹介する。XSMを使うことで、新しいセキュリティ機構を仮想マシンモニタのモジュールとして開発できるようになる。これはLinuxにおけるLinux Security Module（LSM）と同じ考えに基づくものだ。LinuxでLSMを使ってSELinuxなどを実装しているのと同様に、XenでXSMを使ってsHypeなどを実装することができる。

XSMではsHypeと同様に、仮想マシンモニタ内にあらかじめフックを挿入しておき、モジュールとしてさまざまなセキュリティ機構を実装する。現状ではsHypeのACMやSELinuxのベースとなっているFlaskなどが実装されている。XSMはまもなくリリースされるXen 3.2に統合される予定だ。

次回予告

今回は複数のVMを使う際のセキュリティを向上させる仕組みについて解説した。次回ではVMを使うことでVMを使わない場合よりもセキュリティを向上させる研究について解説していく。1月23日（水）公開！ タイトルへ戻る