[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 0/5] add usb redirection filter support



On Tue, Aug 21, 2012 at 09:04:03AM +0200, Hans de Goede wrote:
> 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
-- 
|: 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 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]