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

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

 



On Tue, Aug 21, 2012 at 12:46:41PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/21/2012 11:23 AM, Daniel P. Berrange wrote:
> 
> <Snip>
> 
> >>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.
> 
> One example would be the vm to contain sensitive information and the admin
> not wanting users to be able to redirect USB-mass-storage devices to it,
> while still allowing the use of other USB peripherals. Note that the filtering
> is not just by ID, it also is by class.

I stil don't think this provides any actual security, it is merely a
slight inconvenience. The supposed bad guy has access to both ends,
the guest OS and the SPICE client, so if they want to download data
out of the VM there is no reason they need to expose a USB mass storage
device to the guest. They can tell QEMU they're redirecting a sound card
and QEMU has no way of knowing whether the client side really is a sound
card. The bad guy just cat's the secret data to the sound device in
the guest as "raw audio" and on the client side just save the audio
stream back to a file. Pretty much any kind of USB peripheral will
have some kind of data channel that can be used in this manner, even
if you're just redirecting a keyboard you could transfer data via the
LEDS state, particularly since you're not constrained by limitations
of having real USB hardware on the client side.

> TBH I'm amazed we are having this discussion, everyone I've talked to before
> agrees that allowing a vm admin to limit which kind of USB devices can be
> redirected is a reasonable, desirable even thing to have, and agrees the
> proper place for this, as a per vm setting, is on the host.
> 
> Also note that the proprietary Spice usb-redir solution which the new FOSS
> usb-redir code is replacing has this ability too, and currently you can
> configure a filter from RHEV-M, so from the host / vm management software.

Well I'll withdraw my NACK from this feature, but I maintain that it is
offering little-to-no security.

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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]