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
