On 03/05/2018 02:00 AM, Salvador FandiÃo wrote:In my particular case devices are imported from remote machines. But well, the thing is that I don't care where the connections come from, they could even be devices emulated in user space.
On 02/21/2018 01:35 AM, Shuah Khan wrote:In this use-case:
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.
- 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 withoutNo, that is a different issue. You are talking about controlling which devices can be connected, from which hosts, etc. That is an interesting problem but not the one I am trying to tackle here.
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.
I mean the driver. There might be changes necessary in the user-spaceDid you explore a solution to add a mechanism for access control toCould you elaborate on that?
usbip?
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.>
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.