Re: [Qemu-devel] [PATCH 1/4] Add basic version of bridge helper

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

On 10/07/2011 10:45 AM, Daniel P. Berrange wrote:
> On Fri, Oct 07, 2011 at 10:40:56AM -0400, Corey Bryant wrote:
>>
>>
>> On 10/07/2011 05:04 AM, Daniel P. Berrange wrote:
>>> On Thu, Oct 06, 2011 at 02:38:56PM -0400, Corey Bryant wrote:
>>>>
>>>>
>>>> On 10/06/2011 02:04 PM, Anthony Liguori wrote:
>>>>> On 10/06/2011 11:41 AM, Daniel P. Berrange wrote:
>>>>>> On Thu, Oct 06, 2011 at 11:38:25AM -0400, Richa Marwaha wrote:
>>>>>>> This patch adds a helper that can be used to create a tap device
>>>>>>> attached to
>>>>>>> a bridge device. Since this helper is minimal in what it does, it can be
>>>>>>> given CAP_NET_ADMIN which allows qemu to avoid running as root while
>>>>>>> still
>>>>>>> satisfying the majority of what users tend to want to do with tap
>>>>>>> devices.
>>>>>>>
>>>>>>> The way this all works is that qemu launches this helper passing a
>>>>>>> bridge
>>>>>>> name and the name of an inherited file descriptor. The descriptor is one
>>>>>>> end of a socketpair() of domain sockets. This domain socket is used to
>>>>>>> transmit a file descriptor of the opened tap device from the helper
>>>>>>> to qemu.
>>>>>>>
>>>>>>> The helper can then exit and let qemu use the tap device.
>>>>>>
>>>>>> When QEMU is run by libvirt, we generally like to use capng to
>>>>>> remove the ability for QEMU to run setuid programs at all. So
>>>>>> obviously it will struggle to run the qemu-bridge-helper binary
>>>>>> in such a scenario.
>>>>>>
>>>>>> With the way you transmit the TAP device FD back to the caller,
>>>>>> it looks like libvirt itself could execute the qemu-bridge-helper
>>>>>> receiving the FD, and then pass the FD onto QEMU using the
>>>>>> traditional tap,fd=XX syntax.
>>>>>
>>>>> Exactly. This would allow tap-based networking using libvirt session://
>>>>> URIs.
>>>>>
>>>>
>>>> I'll take note of this.  It seems like it would be a nice future
>>>> addition to libvirt.
>>>>
>>>> A slight tangent, but a point on DAC isolation.  The helper enables
>>>> DAC isolation for qemu:///session but we still need some work in
>>>> libvirt to provide DAC isolation for qemu:///system.  This could be
>>>> done by allowing management applications to specify custom
>>>> user/group IDs when creating guests rather than hard coding the IDs
>>>> in the configuration file.
>>>
>>> Yes, this is a item on our todo list for libvirt. There are a couple of
>>> work items involved
>>>
>>>   - Extend the XML to allow multiple<seclabel>   elements, one per
>>>     security driver in use.
>>>   - Add a new API to allow fetching of live seclabel data per
>>>     security driver
>>>   - Extend the current DAC security driver to automatically allocate
>>>     UIDs from an admin defined range, and/or pull them from the XML
>>>     provided by app.
>>>
>>> Tecnically we could do item 3, without doing items 1/2, but that would
>>> neccessitate *not* using the sVirt security driver. I don't think that's
>>> too useful, so items 1/2 let us use both the sVirt&   enhanced DAC driver
>>> at the same time.
>>>
>>
>> I think I'm missing something here and could use some more details
>> to understand 1&  2.  Here's what I'm currently picturing.
>>
>> With DAC isolation:
>>      QEMU A runs under userA:groupA and QEMU B runs under userB:groupB
>>
>> versus currently:
>>      QEMU A runs under qemu:qemu and QEMU B runs under qemu:qemu
>>
>> In either case, guests A and B have separate domain XML and a single
>> unique seclabel, such as this dynamic SELinux label:
>>
>> <seclabel type='dynamic' model='selinux'>
>>    <label>system_u:system_r:svirt_t:s0:c633,c712</label>
>>    <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel>
>> </seclabel>
>
> If we're going to make the DAC user ID/group ID configurable, then we
> need to expose this to application in the XML so that
>
>   a. apps can allocate unique user/group *cluster wide* when shared
>      filesystems are in use. libvirt can only ensure per-host uniqueness.
>
>   b. apps can know what user/group ID has been allocate to each guest
>      and this can be reported in virsh dominfo, as with svirt info.
>
> ie, we'll need something like this:
>
>    <seclabel type='dynamic' model='selinux'>
>      <label>system_u:system_r:svirt_t:s0:c633,c712</label>
>      <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel>
>    </seclabel>
>    <seclabel type='dynamic' model='dac'>
>      <label>102:102</label>
>      <imagelabel>102:102</imagelabel>
>    </seclabel>
>
>
> And:
>
> # virsh dominfo f16x86_64
> Id:             29
> Name:           f16x86_64
> UUID:           1e9f3097-0a45-ea06-d0d8-40507999a1cd
> OS Type:        hvm
> State:          running
> CPU(s):         1
> CPU time:       19.5s
> Max memory:     819200 kB
> Used memory:    819200 kB
> Persistent:     yes
> Autostart:      disable
> Security model: selinux
> Security DOI:   0
> Security label: system_u:system_r:svirt_t:s0:c244,c424 (permissive)
> Security model: dac
> Security DOI:   0
> Security label: 102:102 (enforcing)
>
> Regards,
> Daniel

Ah, yes.  That makes complete sense.  Thanks for the clarification.

-- 
Regards,
Corey