Hello, > I know that usbip is insecure but personally I think that this series > makes it much more insecure. Later, I remembered USB/IP has TCP wrappers option. It is activated with ./configure --with-tcp-wrappers and /etc/hosts.[deny|allow]. And I tested and found a BUG in my patch which program names for TCP wrappers is not properly set. I posted patch set as v11 including the BUG correction and description about TCP wrappers in the cover letter. Thank you, 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
