possibility of contributing to portal support (USB mass storage)

Winnie Poon winniepoon_home at hotmail.com
Mon Dec 9 19:29:17 UTC 2019


Hi Alex,

Here's a short summary of our use case:

Our application is a remote access client (think: RDP or VNC). One feature is to remote raw USB devices. This allows devices to appear on the remote host as though they were directly plugging in. They would then be subject to whatever permissions, driver support, etc, that is present on the remote host. As such, contrary to typical applications that would use USB devices at a high level (ie: reading files on a flash drive), our application isn't interested in the upper layer and is instead is just a dumb pipe for the USB traffic of arbitrary devices.
<https://teradici.slack.com/archives/CF9FA0G7P/p1575671796143300?thread_ts=1575657638.135400&cid=CF9FA0G7P>
We realize that raw access to arbitrary devices brings its own set of security concerns. Outside a sandbox we use capabilities(7) to gain access to the devices while minimizing the attack surface. From what we've learned thus far, it sounds as though using the same design combined with --device=all is possibly the best choice at present.

Now the problem with --device=all, we found that USB device cannot be dynamically detected, so hotplug didn't work and we need that.

So we were hoping switching to portal solution (we thought there was one) would avoid doing blanket device all access and also address the hotplug issue.

So Alex, for our use case above, which would be a better approach?

  1.  Use --device=all to allow raw access to arbitrary devices.  Is there a way to address the hotplug issue?
  2.  Add portal support for this particular use case and address the hotplug issue in the implementation?

Your valuable opinions will be greatly appreciated!  And again, we would be happy to contribute to the portal support if you think it adds value.

Best Regards,
Winnie




________________________________
From: Alexander Larsson <alexl at redhat.com>
Sent: December 6, 2019 12:45 AM
To: Winnie Poon <winniepoon_home at hotmail.com>
Cc: Flatpak List <flatpak at lists.freedesktop.org>
Subject: Re: possibility of contributing to portal support (USB mass storage)

On Tue, Dec 3, 2019 at 2:37 AM Winnie Poon <winniepoon_home at hotmail.com<mailto:winniepoon_home at hotmail.com>> wrote:
Hi Alex,

Thanks for making things clear.

I would like to explore the possibility of contributing to the portal support for USB mass storage.   A few questions below to help myself and my teammates to get a better idea.


  *   i understand there's no general portal that works for all USB devices, may i know what USB device types we currently have portal support?
  *   from what you said below, it seems like making it work for USB mass storage would be difficult, but would it be possible to come up with a secured solution for that given we have the time and resources to put into it?
  *   if we would like to contribute to the portal support for USB mass storage, we definitely need help from the flatpak developers, what're the general steps/process?
  *   based on your experience from other portal support,  what would be the risks or you have a rough estimate how much time it may take to implement the portal support for USB mass storage?

Your inputs  (or from others who have the experience) would be greatly appreciated.

There is no specific "usb devices" portal, but things like usb webcams are supported via pipewire, usb printers via the printing portal, and the goal for e.g. usb joypads is to deliver input events via wayland. Basically we want to target the solution on the highest level, rather than focusing on transmission details like what bus is sending the data. This way the portals are easier to develop against, easier to make a nice user experience for, and it is easier to reason about their security.

I'm not sure exactly what it is you want to do with USB mass storage, but generally it is *completely* unsafe to allow any user process access to block devices, even in a non-sandboxed environment (you need root access). The "proper" way to handle them is for the host operating system to mount them (automatically or via some interaction) and then access them via the filesystem, using whatever permissions system we have for the files (like the document portal and --filesystem access permissions).

Can you explain your goals at a higher level? What is it the user want to do in a sandboxed app that you want to facilitate?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20191209/b2b531a0/attachment.html>


More information about the Flatpak mailing list