possibility of contributing to portal support (USB mass storage)

[Winnie Poon]

Hi Alex,

First of all, I and my whole team very much appreciate the time and effort you put into helping us with our use cases.   We were all very impressed and astounded when reading your email replies as they all contained very careful thoughts.  Everyone in our team said you're such an amazing guy, we can see your passion in your work!

We're now more convinced that --device=all would be the best choice for us rather than trying to have a portal solution.   We still have to solve the "hotplug" issue.  We use the libusb on ubuntu to handle/detect hotplug event, but it's not working in our flatpak build.   Yes, the device shows up under /dev, but libusb couldn't detect it when it's plugged in after flatpak app has started.    It sounds like from your explanation below it should be possible, so we would try to understand what's blocking libusb from working in the sandbox.

Many thanks again!

Regards,
Winnie


________________________________
From: Alexander Larsson <alexl at redhat.com>
Sent: December 10, 2019 12:43 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 Mon, Dec 9, 2019 at 8:29 PM Winnie Poon <winniepoon_home at hotmail.com> wrote:
>
> 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.
>
> 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.

Yes, I think this is the only way for it to work right now. However,
priority-increasing operations like setuid() and file capabilities
don't work in the flatpak sandbox (or indeed *any* non-privileged
linux user namespace) so depending on your design that may also run
into issues. Something like system-set ACLs on the devices should work
though.

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

How exactly did it fail? --device=all just means that the host /dev is
visible as-is in the sandbox. Any new devices that appear in the
should be visible to you. However, if you rely on udev to tell you
about hotplug events that will not work. Unfortunately the current
udev design depends on apps reading the system-wide udev database, and
that is not ABI stable. I.e. you need to use the exact same libudev
version as the one that wrote the db, which we can't guarantee in the
container case. See here:

  https://lists.freedesktop.org/archives/systemd-devel/2014-October/024498.html

That said, you *should* be able to see the devices show up in /dev and
/sys, so you might be able to get hotplug events some other way. And
if not, it might be possible to have some kind of portal or similar
(ABI stable) service for such events.

> 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, how exactly would such a portal work? I imagine you would call it
with an "open a usb device" request, it would show a dialog with all
the devices on the host that the user has permissions to access, and
then it would open the device and pass back the fd to the user.

As long as this doesn't involve any increase in permissions inside the
portal (which also runs as the user) then this is strictly safer than
--device=all, and would work fine as a portal. However, if it involves
the portal using setuid or file capabilities to get
more-than-regular-user permissions then it sounds very scary.

Also, is this really a useful API for you? It seems kind of limited by
having to do the interaction from scratch each time you want to expose
some device to the remote. I guess we could somehow remember user
choices and let your app silently get access to that device later, but
that seems a bit unsecure (how does the user know when the app has
access? how do you revoke access?).

Also, this depends on details of how the kernel USB device APIs work.
Can we return a file descriptor that is guaranteed to only let you
talk to a particular usb device? Also, can we forcefully revoke the
access via the fd later somehow?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20191221/f75554d0/attachment.htm>