Daniel P. Berrange wrote: > 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 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? -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list