Messages in this thread | | | Subject | Re: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0 | From | Shuah Khan <> | Date | Mon, 5 Mar 2018 17:03:13 -0700 |
| |
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
| |