Re: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

[Shuah Khan]

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