Why does 'usbipd bind/unbind' require administrative privileges? Consider non-admin client support via service

[falhumai96]

I’d like to understand the design decision behind requiring administrator privileges for 'usbipd bind' and 'usbipd unbind'.

Other USB sharing / passthrough solutions (e.g., VirtualBox, VMware) allow non-admin users to attach and detach USB devices using a regular client, while privileged operations are handled by a background service or driver running with elevated rights.

From my understanding, 'usbipd-win' already provides a Windows service that acts as a privileged endpoint responsible for USB operations. Given that, it seems reasonable that:

• The client CLI should not require administrator privileges

• Authorization could instead be enforced by:

  • A Windows group membership check (e.g. 'USBIPD_ALLOWED_USERS' or 'USBIPD_USB_SHARING_USERS')

  • A policy / ACL-based permission model

• The service would remain the only component performing privileged operations

Requiring frequent administrative elevation for basic workflows (bind/unbind) is inconvenient and arguably unnecessary, especially on developer machines. From a security standpoint, I prefer to minimize admin usage as much as possible.

Questions / discussion points:

• Is there a technical limitation on Windows that forces bind / unbind to be admin-only?

• If not, would you consider:

  • Allowing non-admin clients

  • Delegating authorization decisions to the service

  • Supporting an allowlisted Windows group for USB sharing operations

This would significantly improve usability while preserving security boundaries.

Thanks for considering this feature.

[dorssel]

The policy system is intended to solve this. See https://github.com/dorssel/usbipd-win/wiki/New-design:-policies. Try usbipd policy --help. Does that solve your need?

[falhumai96]

I’m not sure I fully understand how the policy command works, but it looks like policies apply only to specific hardware or bus IDs. If that’s the case, it would mean an admin has to add a new policy every time a new device is plugged in and needs to be shared (e.g., with a VM).

What I’m looking for is a way to allow bind/unbind operations on any newly attached hardware without requiring admin privileges. Ideally, members of a designated group—such as a usbipd Administrators group—could perform these actions freely. This would be similar to how the Hyper-V Administrators group works, where users can manage VMs without needing full admin rights.

[dorssel]

I understand what you want. But can you not achieve this by allowing one (or more) bus-ids to auto-bind? I think you can have sufficient functionality with the existing policy rules.

[falhumai96]

What I'm trying to solve is to require Admin just for the usbipd setup and whatever else needed to setup, not requiring Admin access on every new incoming hardware, e.g. to setup autobind on the new hardware. Perhaps I can pass the whole USB hub to usbipd? Not sure if the latter is possible. If so, this might be a solution, but I still feel a group restriction would be a great addition IMO.

[dorssel]

Perhaps I can pass the whole USB hub to usbipd?

No, just individual ports.

But I understand your use case a little better now. The main difference with the policy rules is that with the policy rules "any user can auto-bind a specific port and/or device", and with your "usbipd admin group" "specific users can bind any device". That's interesting enough, so I will put it on the backlog.

One more aspect to solve is bind --force, which requires driver installation privileges. Either we disallow that (i.e., that would still require administrator), or we live with the fact that the "usbipd admin group" members can install any drivers, also for non-USB devices. I am leaning towards the first.

[falhumai96]

Have you considered delegating driver installation and other privileged operations entirely to the Windows usbipd service, with usbipd.exe acting purely as an unprivileged client communicating over IPC (for example, Windows Named Pipes)?

For example:

• usbipd_srv.exe runs as a Windows service at startup and owns all system-level or administrative operations.

• The service exposes two named pipes with different security descriptors:

  • UsbipdAdmin – restricted to members of the usbipd Administrators group, used for privileged actions such as bind, unbind, and policy add or remove (this way it should also support bind with --force).
  • Usbipd – accessible to non-admin users, used for non-privileged operations.

• usbipd.exe never requires elevation itself; it simply routes commands to the appropriate pipe depending on whether the operation requires admin privileges.

This would be similar to how other Windows services expose privileged functionality to non-elevated clients while still maintaining strict access control. I am curious whether this model was considered, and if so, what the constraints were.

[dorssel]

Yes, I have considered that. But I am currently working on a dedicated driver to replace the VirtualBox one. That will also require some redesign in who-does-what. My driver will handle all of USBIP once the device is attached, for much better performance. I don't want to change the current design drastically when it is only temporary.

Anyways, your original request was indeed rather simple to implement. Have a look at #1316. Can you test to see if this is what you intended? Installer can be found here: https://github.com/dorssel/usbipd-win/actions/runs/20007393087?pr=1316

[falhumai96]

@dorssel It works perfectly. Just a small nit: the message usbipd: error: Access denied; this operation requires administrator privileges. might be clearer as something like:
usbipd: error: Access denied; this operation requires administrator privileges or membership in the 'USBIPD Administrators' group.

I’m a big fan of minimizing admin access on my machines (I keep only one local admin account, usually managed by IT—in this case, that’s me 😄).

Thanks again for the change! Please ping this thread when the next release that includes this feature goes out.

[falhumai96]

In the meantime, for anyone following this thread and looking for a way to address this (and similar) issues, I’ve put together a small service/client utility that lets users run a controlled admin command: ControlledAdminCommand. It works much like granting SUID root access to a restricted binary (e.g., passwd) on Unix systems.

I don’t provide pre-built binaries, but the repository includes a PowerShell Core build-and-install script. You’ll need the .NET 10 SDK and the latest PowerShell Core at the time of writing. There’s also a script under Scripts for binding and unbinding USB devices via usbipd-win.

[falhumai96]

Btw, --force doesn't seem to work with the group policy added when used with the bind command (I think you mentioned that above):

PS C:\Users\myhome> usbipd bind -b 10-2 --force
Unhandled exception. System.ComponentModel.Win32Exception (5): DIIDFLAG_INSTALLNULLDRIVER: ERROR_ACCESS_DENIED (5): Access is denied.
   at Usbipd.Tools.ThrowWin32Error(String) + 0x1ac
   at Usbipd.DriverTools.SetNullDriver(WindowsDevice) + 0x142
   at Usbipd.DriverTools.ForceVBoxDriver(WindowsDevice) + 0x13
   at Usbipd.CommandHandlers.Bind(BusId, Boolean, IConsole) + 0x13e
   at Usbipd.Program.<>c__DisplayClass17_2.<<Run>b__23>d.MoveNext() + 0x2cb
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.InvocationPipeline.<InvokeAsync>d__0.MoveNext() + 0x1af
--- End of stack trace from previous location ---
   at Usbipd.Program.<Run>d__17.MoveNext() + 0x391b
--- End of stack trace from previous location ---
   at Usbipd.Program.<Main>d__15.MoveNext() + 0x53
--- End of stack trace from previous location ---
   at Usbipd.Program.<Main>(String[] args) + 0x28

[falhumai96]

Btw, --force doesn't seem to work with the group policy added when used with the bind command:

PS C:\Users\myhome> usbipd bind -b 10-2 --force
Unhandled exception. System.ComponentModel.Win32Exception (5): DIIDFLAG_INSTALLNULLDRIVER: ERROR_ACCESS_DENIED (5): Access is denied.
   at Usbipd.Tools.ThrowWin32Error(String) + 0x1ac
   at Usbipd.DriverTools.SetNullDriver(WindowsDevice) + 0x142
   at Usbipd.DriverTools.ForceVBoxDriver(WindowsDevice) + 0x13
   at Usbipd.CommandHandlers.Bind(BusId, Boolean, IConsole) + 0x13e
   at Usbipd.Program.<>c__DisplayClass17_2.<<Run>b__23>d.MoveNext() + 0x2cb
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.InvocationPipeline.<InvokeAsync>d__0.MoveNext() + 0x1af
--- End of stack trace from previous location ---
   at Usbipd.Program.<Run>d__17.MoveNext() + 0x391b
--- End of stack trace from previous location ---
   at Usbipd.Program.<Main>d__15.MoveNext() + 0x53
--- End of stack trace from previous location ---
   at Usbipd.Program.<Main>(String[] args) + 0x28

From a security perspective, does --force allow installation of arbitrary drivers, or does it only install/uninstall the drivers that usbipd-win manages (i.e., not user-supplied drivers)?

If driver handling is restricted to managed drivers only, could --force be also enabled for users who are members of the USBIPD Administrators group?

[dorssel]

Loading drivers requires SeLoadDriverPrivilege. Although usbipd-win only loads the VirtualBox driver, the user must have this privilege, which could be used (by any program) to load any driver for any device. So, I will not enable that.

[falhumai96]

Loading drivers requires SeLoadDriverPrivilege. Although usbipd-win only loads the VirtualBox driver, the user must have this privilege, which could be used (by any program) to load any driver for any device. So, I will not enable that.

Sorry, I have a couple of questions here:

• First, when does a user require the --force argument when binding a USB? Can you give me an example, please?
• Second, can't the SeLoadDriverPrivilege permission be granted only to the service, and not to any client running the usbipd.exe binary, and it will do the necessary driver install/uninstall on the client's behalf?

[dorssel]

Can you give me an example, please?

It's a rare workaround. Search through past issues / code for reasons. In principle, it shouldn't be necessary.

Seconds: yes, like I said before. But I'm not going to change the interface between service and CLI at this point. Not for a rare case like this. You can always grant that privilege to the new group (or individual users) with Windows security policy manager. But it really is dangerous. I wouldn't.

PS: I am considering using UAC, i.e. use the regular Windows way of temporary elevating privileges when needed.