On Mon, Apr 25, 2022 at 05:45:11PM +0200, Greg Kroah-Hartman wrote: > On Mon, Apr 25, 2022 at 05:17:28PM +0200, Bastien Nocera wrote: > > > > Again, please read the follow-up mail where I talk of the BPF > > > > support > > > > patch that would allow revoking USB fds without relying on a > > > > service in > > > > the middle to access devices (although that's eventually going to > > > > be > > > > the way to do things to allow elevating access to devices). > > > > > > So would bpf be working at the usbfs level here? I still don't > > > understand the connection... > > > > The explanation is here (for hidraw): > > https://gitlab.freedesktop.org/bentiss/logind-hidraw/ > > usbfs is not in that explanation at all. Will there be a logind-libusb > process as well? chiming in here: the hidraw ioctl is independent (as already mentioned) but it's basically the same approach and/or intent. The hidraw revoke ioctl is "the evdev revoke, but for hidraw", this one is "the evdev revoke, but for usb". Not very creative, but at least we can point to prior art and say "this seems to be useful" :) The primary focus of all this are joystick devices (unless I missed some other grand plans Bastien had that I'm not aware of), that should put things in context a bit. Neither ioctl requires a new logind process - logind has TakeDevice(path) and ReleaseDevice() as equivalent to open()/close() and updating the logind *implementation* allows us to "take" a /dev/$whatever node. The (quite short) diff to logind for hidraw is here: https://github.com/systemd/systemd/pull/23140/files It's basically adding a new enum value and then the check for /dev/hidraw instead of /dev/input/event. Imagine the same thing for usb devices. With the ioctls, we need a chain which will require updating libusb etc. so a sandboxed application would do this: application → portal → compositor → logind → open() and the fd being passed back up from that to be used in the application. Ideally libusb can abstract this transparently. This chain is the ideal solution since it allows for tight controls of what the application can access, including the required "are you sure?" UI inserted where needed. Both logind and the portal would have a copy of the fd to call revoke on it when required (e.g. user switch or something interactive in the portal). Alas, this chain requires updates to how the application opens the fd. Benjamin's suggestion of using BPF (in addition to the ioctl) allows us to implement permission checks without that chain in place. With the right BPF program loaded, logind can effectively revoke an fd even where logind wasn't in the actual open() chain. For user-switching this immediately works, we need no application updates. For the "are you sure?" UI part it's more complicated but as a thought exercise: the portal could tell logind that $path was ok to be opened by any application, logind then allows that. If the portal tells logind that it's not longer ok, it can revoke any open fd. The portal does not need to know who actually has an fd open. There's some discussion on this "how's this actually going to work?" issue here: https://gitlab.freedesktop.org/bentiss/logind-hidraw/-/issues/1 just mentally substitute hidraw with usb. Notably, the application itself does not need updates. There are other efforts like that complement all this, like the proposal to tag "safe enough" joystick devices as such so they can be opened by an application: https://github.com/systemd/systemd/pull/22860 > But back to the original question, what programs would use this that > today offer direct access to USB devices through libusb? I can maybe > think of some fingerprint scanners and some flatbed scanners (printers?) > But those are generally rare and the fingerprint scanners only have > limited access to the device already. > > You're going to have to test this somehow with some program, what are > you using today for this? I have a very simple hidraw tester here: https://github.com/whot/hidiocrevoke-test/blob/master/revoke.c Updating that to take usb devices can't be that hard :) hth Cheers, Peter
