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

On Tue, Oct 21, 2008 at 09:57:15AM -0400, Daniel J Walsh wrote: > James Morris wrote: [snip] >> The domain security label configuration format is as follows: >> >> # virsh dumpxml sys1 >> <domain> >> .... >> <seclabel model='selinux'> >> <label>system_u:system_r:virtd_t:s0</label> >> <policytype>targeted</policytype> >> </seclabel> >> </domain> >> >> It's possible to query the security label of a running domain via virsh: >> >> # virsh dominfo sys1 >> Id: 1 >> Name: sys1 >> UUID: fa3c8e06-0877-2a08-06fd-f2479b7bacb4 >> OS Type: hvm >> State: running >> CPU(s): 1 >> CPU time: 11.4s >> Max memory: 524288 kB >> Used memory: 524288 kB >> Autostart: disable >> Security label: system_u:system_r:virtd_t:s0 (selinux/targeted/enforcing) [snip] > Why do we care about the policy type? Policy type is a fairly > meaningless object. If you are trying to figure out if the host machine > is valid to run a virtual machine you should just check whether the type > is valid on the machine, That way if I define minimum policy with virt > support on one host and targeted policy with virt support on another > machine, both would work. Finally I think it might be ok for the > administrator to request that this virtual machine would only run on a > machine with SELinux in enforcing mode. For example if you had a fairly > untrusted virtual machine you would want to ensure that the machine was > enforcing SELinux before it got started. Who/what should be making such a policy decision though ? Seems like the management app using libvirt would want to do that - perhaps even making that decison before defining the existance of the VM on the target machine, let alone starting it. When migrating a VM from one host to another an application may also want to verify that the same policy is available on both the source and target hosts. A simple 'targeted' vs 'enforcing' string is likely not sufficient in this context. This also feels like host level info, rather per-VM. I think the 'policytype' bit of the label may thus better live in the host capabilities XML document, so you can query it independantly of any virtual machine eg perhaps something like # virsh capabilities <capabilities> <host> <cpu> <arch>i686</arch> </cpu> <secpolicy model='selinux'> <type>targetted</type> <state>enforcing</state> </secpolicy> </host> .... snip rest of XML... Is there any meaningful / useful policy version information that can be included here ? Or policy feature bits The VM config would thus only need <domain> .... <seclabel model='selinux'> <label>system_u:system_r:virtd_t:s0</label> </seclabel> ... </domain> 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. Daniel