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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55943213.6040901@codeweavers.com>
Date:	Wed, 01 Jul 2015 13:31:47 -0500
From:	Jeremy White <jwhite@...eweavers.com>
To:	"Daniel P. Berrange" <berrange@...hat.com>
CC:	hdegoede@...hat.com, spice-devel@...ts.freedesktop.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to
 remotely connect USB devices over IP.

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

Good point.  For completeness, I'll note that, in a Spice use case, the
data would be encrypted by the normal Spice mechanisms.  And it would be
fairly straight forward to write a user space daemon that would accept
TLS and then relay to the unencrypted socket (of course, it would
rewrite everything, which would be inefficient).

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

And that would also eliminate the need to copy the parsing code, which
would be a nice improvement.

I considered this approach, but discarded it, perhaps wrongly, when my
google fu suggested that netlink sockets were the best way to connect
user space and a kernel module.  (Because I perceived netlink sockets to
be functionally equivalent to the relay daemon described, above).

>From the user space perspective, the usbredir parser has an interface
that exposes about 20 callback functions, which are invoked with
pointers to a variety of structures.  The ideal would be to have a
mechanism to 'call into' kernel space with those varying interfaces.

Would using ioctls be a reasonable way to achieve this?  Is there a
better way?

In the other direction, the usbredir hc provides a range of functions; I
think most interesting are the urb en/dequeue, hub control, and hub
status calls.  Some of that can be handled in the driver; some would
need to be passed on to user space.

My google fu did not lead me to an obvious way to pass this information
to user space.  The approach that comes to mind is to use a signal, or
woken socket, to instruct user space to poll.

I'd appreciate further comments and advice.

Cheers,

Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/