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タイプに変換して扱う。

図3：MACドメインを介した資源アクセス

さらに、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に統合される予定だ。