USB Gadget Stack Protection

[grant-h]

On mobile devices, USB host mode is not the default. Instead, the Linux gadget stack is active.
Gadgets allow an operating system to act as any USB device type, provided there is driver support.
Here is a good overview of the kernel gadget stack: https://www.kernel.org/doc/html/v4.19/driver-api/usb/gadget.html

Gadget drivers (drivers/usb/gadget/function) register to the USB composite driver (drivers/usb/gadget/composite.c) via the DECLARE_USB_FUNCTION_INIT macro. The composite driver is easily configured by ConfigFS (drivers/usb/gadget/configfs.c), which can be mounted and exposed to userspace. This allows userspace to easily attach and modify gadget parameters just by reading and writing files. This is how Android manages its gadget configuration (Android platform/system/core/rootdir/init.usb.configfs.rc).
As a side note, ConfigFS isn't strictly required. There are legacy ways of mounting gadgets (see this presentation: Kernel USB Gadget Configfs Interface)

To be able to guard against gadget function exposure when not needed, there isn't a kernel-level API like USB authentication available. I'm not sure a userspace only addition to USBGuard would do the trick. Hardening the gadget stack would likely require some USB hooks in the kernel to be able to centrally enforce policy, regardless of ConfigFS directory contents.

[tweksteen]

Thanks Grant. @dkopecek @radosroka would you consider expanding the scope of USBGuard to cover gadgets?

[dkopecek]

Thanks Grant. @dkopecek @radosroka would you consider expanding the scope of USBGuard to cover gadgets?

@tweksteen I'm not against it. At this point I'm not familiar with technical details about how the gadgets work and how we could enforce policies via USBGuard. @grant-h mentions that Kernel side support is likely required so we would need some experienced Kernel hacker on our side.

[tweksteen]

Ack. I'll assign myself and update any progress here. Thanks

[DylanVanAssche]

Hi!

I wonder if USBGuard is open for expanding it in the following way:

• Management of UDC by confguring gadgets via a DBus API. For example: create a NCM ethernet USB gadget or configure a FunctionFS gadget with an userspace daemon like uMTP-Responder for MTP.
• Rules to allow or block the exposure of these gadgets. If the user does not allow any data transfer (charging mode), USBGuard refuses to create the USB gadgets via DBus.
• Some gadgets require additional daemons or userspace scripts like MTP, before the gadget is enabled by writing to the UDC, the userspace daemon must be launched. When the gadget is disabled, the daemon needs to be stopped.

Is this a possibility to get such patches in as Pull Requests?