Hi,
On 08/20/2012 06:06 PM, Daniel P. Berrange wrote:
>On Sun, Aug 19, 2012 at 11:42:43PM +0800, Guannan Ren wrote:
>>BZ RFE
https://bugzilla.redhat.com/show_bug.cgi?id=795929
>>qemu support:
>>http://git.qemu.org/?p=qemu.git;a=commitdiff;h=6af165892cf900291046f1d25f95416f379504c2
>>
>>Since qemu has have the code to support USB redirection filter. This set of
>>patches try to support it from libvirt.
>>The XML format is like this:
>> <devices>
>> ...
>> <redirdev bus='usb' type='spicevmc'>
>> <address type='usb' bus='0' port='4'/>
>> </redirdev>
>> <redirfilter>
>> <usbdev class='0x08' vendor='0x1234'
product='0xbeef' \
>> version='2.00' allow='yes'/>
>> <usbdev class='-1' vendor='-1' product='-1'
version='-1' allow='no'/>
>> </redirfilter>
>> ...
>> </devices>
>I don't really see the point in this being done on the libvirt side.
>The <redirdev> code is allowing redirection of a USB device from a
>client (eg SPICE) app, to the remote QEMU instance and from there to
>the guest.
>
>With this architecture, IMHO filtering of USB devices is something
>that belongs in the client app, not in QEMU which is a broker inbetween
>the client & guest OS.
We want the admin of the vm to be able to set policy as to which devices
can be redirected to the vm, for example for security reasons. Clearly the
right place to enforce such a policy is the host and not the client, esp.
since the client may be outside of the control of the vm admin.
What kind of threat are you expecting this to protect against ? I don't
really see that black/white-listing on vendor/product ID is going to
provide a very credible level of security protection. Chances are that
if there is a flaw in the guest OS or QEMU, the attacker could simply
spoof the required product/vendor ID and then send specially crafted
USB packets to exploit the flaw anyway.
Daniel
--
|: