On 03/05/2018 02:00 AM, Salvador Fandiño wrote: > On 02/21/2018 01:35 AM, Shuah Khan wrote: >> Hi Salvador, >> >> On 01/30/2018 01:36 AM, Salvador Fandino wrote: >>> Let me start by explaining the problem that have motivated me to write >>> this patches: >>> >>> I work on the QVD, a virtual desktop platform for Linux. This software >>> runs Linux desktops (i.e. XFCE, KDE) and their applications inside LXC >>> containers, and makes then available through the network to remote >>> users. >>> >>> Supporting USB devices is a common feature customers have been >>> requesting us for a long time (in order to use, for instance, remote >>> signature pads, bar-code scanners, fingerprint readers, etc.). So, we >>> have been working on that feature using the USB/IP layer on the >>> kernel. >>> >>> Connecting and disconnecting devices and transferring data works >>> seamless for the devices listed above. But we also want to make the >>> usbip operations private to the container where they are run. For >>> instance, it is unacceptable for our product, that one user could list >>> the devices connected by other users or access them. >>> >>> We can control how can access every device using cgroups once those >>> are attached, but the usbip layer is not providing any mechanism for >>> controlling who can attach, detach or list the devices. In this use-case: - does a container act as usbip client and attach devices from their host? - do containers attach remote devices from other systems? Is the core of the problem really that any remote system can import without a provision for being able to restrict export to a set of remote machines? If so, this is a generic problem even without containers and I would like to solve this with a generic solution that works in all cases, not just for containers. The approach in this patch series appears to solve the problem just for containers. >> >> Did you explore a solution to add a mechanism for access control to >> usbip? > > Could you elaborate on that? > > For "usbip", do you mean the user space tools? > If that is the case, I don't think it would be enough. > My aim is to limit vhci usage from containers and I have no control about what runs inside the containers. So, a mangled usbip tool-set could > > be used by a malicious user to circumvent any access control set there.> I mean the driver. There might be changes necessary in the user-space as well depending on how the access controls are implemented. I am not proposing implementing access controls in the user-space. > IMO, there is no other choice but to control access to VHCI at the kernel level. > Probably. Please give as many details as possible on your environment for me to make a call on if this problem can be solved in a different way. thanks, -- Shuah -- 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
