Thank you for your comments,
> I know that usbip is insecure but personally I think that this series
> makes it much more insecure.
> 1) usbipa ... start daemon
> your server is opened for connecting any random device from the net.
Yes, I think so too.
> For now I see at least one simple solution to modify WebSocket proxy
I agree.
I wrote same solution as 'security consideration' in the cover letter.
--- snip ---
In new operation, when the daemon is running, SSL or Secure WebSocket
tunneling proxy can reject unauthorized access.
---
> As far as I can see, our main use case is to bypass the firewall
I started from the bypass firewall use case.
Now, I'm thinking new operation ('connect' command) is worth for others,
for example, connecting IoT devices to server room inside firewall.
> I don't understand why you don't want to solve this problem simply in
> userspace?
I'm not clear about this question but I try.
At v7, userspace transmission and WebSocket command/daemon have been
removed from this series because I took comments it can be done by
userspace proxy.
So this series is just adds new operations 'connect' and 'disconnect'
command to existing 'bind' and 'unbind' at device side and 'attach'
and 'detach' at application side.
The security consideration after starting daemon is discussed above.
Another issue is whether the new operation is worth.
If a connection between WebSocket proxies is established wrapping 'connect'
or 'attach', the direction must from inside firewall. It depends whether
daemon is inside or outside. According to the direction, one of the new
or existing operation will work. Using VPN, the directions is not problem.
I think it is better that users can choose appropriate manner from both
operations.
At least, we conveniently use the new operation including small
peer-to-peer environments. I hope it will be of some help.
Best Regards,
n.iwata
//
> -----Original Message-----
> From: Krzysztof Opasiak [mailto:k.opasiak@xxxxxxxxxxx]
> Sent: Wednesday, August 10, 2016 2:28 AM
> To: fx IWATA NOBUO; valentina.manea.m@xxxxxxxxx; shuah.kh@xxxxxxxxxxx;
> gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx
> Cc: fx MICHIMURA TADAO
> Subject: Re: [PATCH v9 0/9] usbip: exporting devices
>
>
>
> On 07/11/2016 09:23 AM, Nobuo Iwata wrote:
> > Dear all,
> >
> > This series of patches adds exporting device operation to USB/IP.
> >
> > 1. Overview
> >
> > Exporting devices may not be a new idea. The request and response PDU
> > have been defined in tools/usbip/usbip/src/usbip_network.h.
> > #define OP_EXPORT 0x06
> > #define OP_REQ_EXPORT (OP_REQUEST | OP_EXPORT)
> > #define OP_REP_EXPORT (OP_REPLY | OP_EXPORT)
> > # struct op_export_request
> > # struct op_export_reply
> > #define OP_UNEXPORT 0x07
> > #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT)
> > #define OP_REP_UNEXPORT (OP_REPLY | OP_UNEXPORT)
> > # struct op_unexport_request
> > # struct op_unexport_reply
> >
> > But they have not been used yet. This series adds new operations:
> > 'connect' and 'disconnect' using these PDUs.
> >
> > EXISTING) - invites devices from application(vhci)-side
> > +------+
> +------------------+
> > device--+ STUB | | application/VHCI |
> > +------+
> +------------------+
> > 1) usbipd ... start daemon
> > = = =
> > 2) usbip list --local
> > 3) usbip bind
> > <--- list bound devices --- 4) usbip list --remote
> > <--- import a device ------ 5) usbip attach
> > = = =
> > X disconnected 6) usbip detach
> > 7) usbip unbind
> >
> > NEW) - dedicates devices from device(stb)-side
> > +------+
> +------------------+
> > device--+ STUB | | application/VHCI |
> > +------+
> +------------------+
> > 1) usbipa ... start
> > daemon = = =
> > 2) usbip list --local
> > 3) usbip connect --- export a device ------>
> > = = =
> > 4) usbip disconnect --- un-export a device --->
> >
> > Bind and unbind are done in connect and disconnect internally.
> >
> > 2. The use cases
> >
> > EXISTING)
> >
> > In existing way, computers in small distance, having same user
> > account, can be easily managed by a same user. Bind in local machine
> > and attach in remote machine by the user. The devices can be exporsed
> > automatically in the local machine, for example, at strat up. They can
> > be attached from remote.
> >
> > When there are distributes linux nodes with USB devices in internet,
> > they are exposed by bind operation at start upr, server behind
> > firewall can list and attach the devices.
> > Internet
> > Exposed +----------+ +--------+ +--------+
> > +------+ |Linux |+ |Router, | |Service |
> > +|device|--|Controller||-------------------|proxy, |----|on |
> > |+------+ +----------+| |firewall| |Linux |
> > +------+ +----------+ +--------+ +--------+
> > <--- attach(import)
> > USB/IP + WS proxy WS proxy + USB/IP
> >
> > NEW)
> >
> > Assuming that a server computer which runs application and VHCI is in
> > a server room and device side machines are small distributed nodes
> > outside of the server room, the operator of the server compter is
> > different form the distributed nodes. The server computer may be in
> > unattended operation. In the new way, after the daemon has been
> > started, device can be connected with connect command in the
> > distributed nodes. If the distributed nodes doesn't have user
> > interface, the connect command can be executed from start up procedure.
> >
> > In another senario to connect devices to a Linux based cloud service
> > using WebSocket proxy, it's needed to establish connection from a
> > device inside of firewall to a service outside. Exporting is suitable
> > for the senario.
> >
> > Home/SOHO/Intranet Internet
> > +----------+ +--------+ +--------+
> > +------+ |Linux |+ |Router, | |Internet|
> > +|device|--|Controller||----|proxy, |-------------------|service |
> > |+------+ +----------+| |firewall| |on Linux|
> > +------+ +----------+ +--------+ +--------+
> > connect(export) -->
> > USB/IP + WS proxy WS proxy + USB/IP
> > ex)
> > Device Service
> > sensors ......................................... environment
> > analysis cameras .........................................
> > monitoring, recording ID/biometric readers
> > ............................ authentication
> >
> > Connection from outside firewall is usually blocked.
> > So existing import request sent with attach command doesn't work.
> >
> > # usbipd (blocked)|| <--------- # usbip attach
> >
> > Firewall opens some ports, usually HTTP(80) and HTTPS(443), from inside.
> > Then export request sent with new connect command works.
> >
> > # usbip connect -----------------------------> # usbipa
> > (passed)
>
> To be honest I'm really afraid of this series...
>
> I know that usbip is insecure but personally I think that this series makes
> it much more insecure.
>
> After executing:
>
> 1) usbipa ... start daemon
>
> your server is opened for connecting any random device from the net. It
> means that *any* computer from the network can connect to this server and
> provide *any* type of USB device (for example emulated using vudc) and
> do what ever it wants (for example use badUSB attack or try to exploit some
> vulnerable USB device driver).
>
> As far as I can see, our main use case is to bypass the firewall but I don't
> understand why you don't want to solve this problem simply in userspace?
>
> For now I see at least one simple solution to modify WebSocket proxy on
> Server side to notify about each new authorized connection and your
> userspace can automatically verify if this new connection exports one of
> allowed devices and connect it or terminate the connection. Am I missing
> something or it should be really enough?
>
> Best regards,
> --
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
