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
