New design: policies

[dorssel]

This is the discussion thread for a new design. See https://github.com/dorssel/usbipd-win/wiki/New-design:-privilege-system.

[dorssel]

@benmcmorran
@andrewleech
@christophmuellerorg

You've expressed interest into this feature. Please chime in.

[benmcmorran]

Sorry about the delay. I'm less professionally involved in the embedded development that uses this project than I used to be, but the proposal looks good to me.

[dorssel]

Making this a little more versatile, allowing for other "types of rules" later:

usbipd rule add allow auto-bind [--busid <BUSID>] [--hardware-id <VID:PID>]

etc.

This allows:

• A single sub-command for all "rules"
• rule add, rule remove, rule list for all kinds of rules in the future
• adding rules: next subdivision into allow and deny
• final subdivision (the subject for this feature): auto-bind, making it clear what it actually does: automagically "as if" bind

Future stuff could include: usbipd rule add allow client, usbipd rule add deny attach, etc.

Alternative order (I like this slightly less):

usbipd rule add auto-bind allow [--busid <BUSID>] [--hardware-id <VID:PID>]

[dorssel]

Next up for debate: call it usbipd rule or usbipd rules?

[christophmuellerorg]

Thanks! Sorry for the delay, I have been on vacation for a few days. This looks like a great way to handle permissions and covers my use case of allowing to use embedded programmers inside WSL perfectly.

[andrewleech]

So just to be clear, these rules are not currently to auto-attach a device to WSL whenever they're plugged in, more like a way to preemptively admin/auth devices before they're plugged into the system?

Would there be a way to use a wildcard on the device ID, to match like vid=0987&pid=&serial= to auto bind anything with the specific vid for example?

In terms of integrating this into my GUI app, I've got a rules system for auto-attach that I could probably update to use this as well, allowing users to optionally type in the device ID etc rather than an existing device.

[dorssel]

I'm not sure if there are particularly serious security implications of that.

Well, yes, there are. USBIP is totally insecure. Plaintext, and no authentication system. That means that, in principle, anyone that can somehow access port 3240 can claim a shared device. This includes keyboards (key-logging) and webcams (privacy). To make it at least slightly secure, usbipd-win (or rather, the firewall rule it installs) restricts access to local subnets only. See rationale here: #249 (comment). Note that since WSL mirrored networking (in combination with the fact that some people use ssh tunneling) it is also impossible to tell if a "remote" connection is really remote, local, WSL, or whatever...

The service already runs with full privileges (LOCAL SYSTEM). It was me who decided that an Administrator must first explicitly allow a device to be remotely attached.

TL;DR: A carte blanche so anyone (non-admin) can attach any an all devices (including security critical devices) is a no go. This feature just make the Administrator's life just a little easier.

[christophmuellerorg]

My use case for a wild card on the PID would be to allow for example all FTDI interface chips as there is a whole bunch of them in use for all kinds of JTAG / I2C / SPI / UART interfacing tasks (FT4232, FT2232, FT4222, ... ) and at least right now FTDI doesn't produce any other potentially safety critical devices. An other use case would be to allow for the everything with the company VID to be whitelisted in an R&D department. This feature could also be used with a later usb class based disallow filter to formulate rules like "everything from company X but HID class devices" or similar.

[andrewleech]

USBIP is totally insecure. Plaintext, and no authentication system. That means that, in principle, anyone that can somehow access port 3240 can claim a shared device. This includes keyboards (key-logging) and webcams (privacy).

Ah yes that does make sense, so yes making it more difficult for users to accidentally give too much remote access makes sense.

Tangential note; maybe an option to set allow/deny lists for client IP addresses would be good for security. I'd love to give unrestricted access to WSL running on the same machine, but limit lan access.

[dorssel]

See #916. You now have to specify --type bind, but in the future --type attach could also be added. And then it makes sense to add a --client <IPADDRESS> selector. For now, firewalling is out-of-scope. The current policies are intended to be "device centric" (as in: which device is allowed). Firewalling policy (possibly added in the future) is "client centric" (as in: who is allowed).

[dorssel]

@christophmuellerorg
I can imagine that some R&D department has multiple devices in development. But not 10+. And in any case I am sure there is some internal company registry that must be administering the assigned PIDs. That's not something developers "make up on the fly". Adding 10 policy rules (a one-time-only effort) is easy enough.

On the other hand, a wildcard vendor selector makes it just a little too easy for dumb administrators to say: we allow you to forward your Logitech headset, but we don't know the exact PID, so, YOLO, we'll just allow all Logitech products (including webcams and keyboards).

Long story short: as a security architect, I am allergic to sentences containing both the words "policy" and "wildcard".

[dorssel]

I've made a first implementation, it is at #916

I've also updated the design document: https://github.com/dorssel/usbipd-win/wiki/New-design:-policies

New syntax uses the terminology "policy", which is made up of "policy rules" (or simply "rules"). Rules can be added, removed, and listed.

Feel free to try out the build from the PR and play with it a bit.

[dorssel]

One more change to the terminology. #916 is ready to be merged.