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

[Daniel J Walsh]

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?