On Wed, Oct 22, 2008 at 08:50:19PM +1100, James Morris wrote: > 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? The data in the host capability XML is interpreted wrt the hypervisor connection URI you gave to virConnectPtr. So if you open two libvirt connections, one with qemu:///system and one with 'xen:///' on the same physical host, it is expected you will see alternative views of that host. As just one example, if you opened 'qemu:///system' on a Xen enabled host you'd only see a view of the world that covers the hardware available to Domain-0. This can be a subset of the hardware seen by the hypervisor itself. If you opened 'xen:///' then you'd see the full view. So, what this means for security models - if you opened 'qemu:///system' on a Xen enabled host you'd likely see a SELinux security model, whereas 'xen:///' would likely show you an XSM security model. That said in normal circumstances we don't expect that people will use multiple different virtualization technologies within the context of a single OS instance. You may however see nested virtualization, eg, a Fedora 9 KVM host, runs a RHEL-5 xen guest, which runs a Windows guest. There are even patches for KVM to let it expose SVM hardware virt to the guests. libvirt does not try to track this nesting explicitly - its viewpoint is always limited to a single hypervisor connection. The intent is that libvirt provides enough metadata, to allow an external mgmt application to build up a complete 'world view' of all its data center, correlating guests & hosts, primarily via the UUID. > - 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> I think to start with we probably just assume a single security labelling model per hypervisor connection. If a single host happened to have multiple models, I believe each model would likely be scoped to a specific hypervisor on the host. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list