Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote:
> This module uses the usbredir protocol and user space tools,
> which are used by the SPICE project.
> 
> Signed-off-by: Jeremy White <jwhite@codeweavers.com>

[snip]

> diff --git a/drivers/usb/usbredir/Kconfig b/drivers/usb/usbredir/Kconfig
> new file mode 100644
> index 0000000..284fd02
> --- /dev/null
> +++ b/drivers/usb/usbredir/Kconfig
> @@ -0,0 +1,25 @@
> +config USBREDIR
> +	tristate "USBREDIR support"
> +	depends on USB && NET
> +	---help---
> +	  This enables connecting a remote USB device over IP using
> +          the USBREDIR protocol.  This module provides a sysfs attach
> +          interface which, if given a socket connected to a remote
> +          usbredirserver, will enable the remote device to behave as
> +          though it were connected to the system running this module.
> +
> +          For more information and user space tools, refer to the
> +          USBREDIR project, which can be found at
> +          http://www.spice-space.org/page/UsbRedir.

[snip]

> new file mode 100644
> index 0000000..217a2e4
> --- /dev/null
> +++ b/drivers/usb/usbredir/README
> @@ -0,0 +1,20 @@
> +USB Redirection Kernel Module
> +
> +This module allows a Linux system to instatiate USB devices
> +that are located on a remote device.  The USB data is transferred
> +over a socket using the USBREDIR protocol, which is generally
> +used in conjunction with the SPICE project.
> +
> +You will need the USBREDIR user space tools.  They can
> +be found at http://www.spice-space.org/page/UsbRedir.
> +
> +To use, start the usbredirserver on a remote system.
> +For example,
> + ./usbredirserver --port 4000 125f:db8a
> +will export my ADATA thumb drive on the remote system.
> +
> +Next, on the local system, connect a socket and relay that to
> +the kernel module.  The connectkernel utility will do this as follows:
> +  ./connectkernel adata4000 my.remote.device.com 4000
> +
> +The device should attach and be usable on the local system.

What is the security story here ? If I am understanding correctly, you have
a userspace helper which opens a socket, and does a connect() to establish
the connection to the remote system, and then tells the kernel to use the
file descriptor associated with the socket.

Assuming that's correct, then this seems to imply that the socket has raw
plain text data being sent/received, and thus precludes the possibility
of running any security protocol like TLS unless the kernel wants to have
an impl of the TLS protocol.

I don't really think it is sensible to be defining & implementing new
network services which can't support strong encryption and authentication.
Rather than passing the file descriptor to the kernel and having it do
the I/O directly, I think it would be better to dissassociate the kernel
from the network transport, and thus leave all sockets layer data I/O
to userspace daemons so they can layer in TLS or SASL or whatever else
is appropriate for the security need.

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