[libvirt] Re: [RFC] sVirt v0.10 - initial prototype

James Morris jmorris at namei.org
Wed Oct 22 09:50:19 UTC 2008


On Tue, 21 Oct 2008, Daniel P. Berrange wrote:

> I should note that the domain XML format is representative of the config
> for a particular deployment of a virtual machine onto a host. 
> 
> It is not a generic interchange format for 'appliances'. If you were
> distributing an appliance, then the virt-image XML format would be used,
> and this encodes information on pre-requisites for host capabilities. 
> 
> When an appliance is deployed as a virtual domain, the virt-image tool,
> validate the virt-image XML pre-requisites, against the host capabilites
> XML to determine if the host is suitable.

As you mention in a later email, enforcing mode can be set on a 
per-process (domain) basis, so for the case of domain labeling, the 
current enforcing status needs to be bound to the domain.

In terms of migration and provisioning, we need to consider several issues 
in more detail (some perhaps later), e.g.:

- It should be possible to migrate an "isolated" domain between different 
  types of security models if each supports it (e.g. from Smack to 
  SELinux);

- How do we handle different types of virtualization running on the same 
  host, e.g. qemu domains running inside containers?

- Policy for import and export of domains, including translation of 
  labels when imported.

Initially, though, perhaps just stick with the simplest case of listing 
which security models and DOIs are supported, and I think we should stick 
with 'seclabel' rather than introduce 'secpolicy'.

  <host>
     ...
     <seclabel model='selinux'>
       <doi>engineering.example.com.</doi>
       <!-- any other supported DOIs... -->
       <enforcing>yes</enforcing>
     </seclabel>

     <!-- any other active security labeling models ... -->

  </host>




-- 
James Morris
<jmorris at namei.org>




More information about the libvir-list mailing list