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
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
