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 Again targeted means nothing. It is just an arbitrary name given to a
Daniel P. Berrange wrote: policy package. So I don't see why it should be mentioned anywhere. I think the existance of the kernel policy which understands what a system_u:system_r:virtd_t:s0 is what is important. Again, I could have a three host machines each one with a different policy package say targeted, mls and overt policy package. If all three understand what a system_u:system_r:virtd_t:s0 type is, then all three could run the image. Having two machine with a "targeted" policy on them does nothing to assure that a processs labeled system_u:system_r:virtd_t:s0 can run. As far as enforcing mode is concerned, I thought that you could require that this virtual machine could only run on machines with SELinux in enforcing mode. so wouldn't that be associated with the virtual machine?