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

Daniel J Walsh dwalsh at redhat.com
Tue Oct 21 17:50:20 UTC 2008

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?

More information about the libvir-list mailing list