USB Mouse Connect Automatically to dom0

[JoanaBanana]

that’s weird, that bulletin is from 2018. I installed 4.1 a few weeks ago.
And I tested with a USB mouse, and the policy works.
I guess the problem is because of the “unified” dongle, that can be a mouse and a keyboard and qubes allows it automatically.

[zithro]

Sorry, you’re right indeed, only qubes.ClipboardPaste is using the @ sign, all others have still $ in my recent 4.1 install, I guess for retro compatibility.

@JoanaBanana

I guess the problem is because of the “unified” dongle, that can be a mouse and a keyboard and qubes allows it automatically

I imagine you are right, I’ve read somewhere there’s a mechanism that prevents USB keyboards from being grabbed and that “multifunction” USB devices have glitches in Qubes (maybe in github, have you looked there ?).

@JoanaBanana

Should we suggest a new feature to qubes team to detect this kind of edge cases?

Given the ubiquity of those devices, I imagine that it could even be filed as a bug : solving it may prevent unexpected behaviours and confuse new/non-technical users.

[enmus]

NOTE:
The following line enables compatibility mode. It reads files in old directory
(/etc/qubes-rpc/policy). It also generates deny rules that were previously
implicit after each file, but they are added only after policies for specific
arguments, that is, for files with ‘+’ in the name. For generic files, without
‘+’, no such rules are generated and the control “falls through”, which is
a departure from previous semantics. It is done that way not to shadow the
default rules.
The “!compat-4.0” directive is transitional only and will be unavailable in
next major release (R5.0). This file will be removed in that release also.

!compat-4.0

From /etc/qubes/policy.d/35-compat.policy?

[JoanaBanana]

can’t find any issue on github.
I will suggest a new feature.
While it may be a bug I can think about many situations where it may be intended.

[JoanaBanana]

However…
Considering this a security issue, which is my main concern, there’s no real bug here, because by using “qvm.usb-keyboard”, any keyboard is also attached automatically to dom0. So you already lost because you’re are vulnerable to badusb attacks by emulating a keyboard.
In my opinion there should be some kind of granular control on the policies, as example, automatically allowing just one keyboard device, and bind it internally so that any badusb with same PID:VID wont be able to bypass that policy.
Does it make sense?

[zithro]

Well first, I’m must say I’m a Qubes novice (but not Xen), and I can’t use USB on Qubes yet with a dedicated PCI-PT USB controller, so can’t test, and don’t fully understand how the devices are handled.
But I’m rather paranoid and as such interested about your use case, so I have a few remarks :

• I’m also concerned about such rogue devices, but if the same PID:VID, I don’t know if the system could distinguish between the two. I know though you could use some sort of hardware dongle in-between, like a microcontroller like the small Arduino/Raspberry. IIRC you can specify your own PID:VID.
• your dongle is using the same USB port for mouse+kb, and as I don’t know how it’s handled by Qubes take what I say cautiously, but from what I know on vanilla Xen (without libvirt) you cannot assign a USB port to another domain, rather a device.

[JoanaBanana]

I also don’t have the full knowledge how these devices are handled by xen and qubes, but maybe we could use some static information about the device/USB since this is a laptop internal keyboard and it is always connected/mapped to the same USB port, could we use that information to allow only that specific device?
Could someone from the qubes team give some feedback about this improvement?

[zithro]

@zithro

you cannot assign a USB port to another domain

Bad memory, that is plain wrong, as I just read on Xen USB Passthrough.
Excerpt :

USB devices are primarily specified either by their bus address (in the form bus.device) or their device tag (in the form vendorid:deviceid).
Each way of specifying has its advantages:

• Specifying by device tag will always get the same device, regardless of where the device ends up in the USB bus topology. However, if there are two identical devices, it will not allow you to specify which one.

• Specifying by bus address will always allow you to choose a specific device, even if you have duplicates. However, the bus address may change depending on which port you plugged the device into, and possibly also after a reboot.

In your case, and everyone’s using an internal keyboard on a laptop, the bus address/port will never change ! So even with the same PID:VID, no way to be messed around. I’m just not sure what they mean by “the bus address may change […] possibly also after a reboot”. Maybe if USB controllers are added ? That needs investigation.

From my nooby standpoint, I see two ways of doing this in Qubes :

• having a kernel line using “rd.qubes.hide_all_usb,except=(USB_BUS,USB_DEVICE)”
• having a “InputKeyboard” policy or “qvm.usb-keyboard” with the same exception thing

But maybe you should create another post with another title, more meaningful to the request ?
Because there are two subjects in this discussion : the Unifying problem, and the “exception” for the internal keyboard.

PS: just curious, why not usbguard ?

[rjt]

@JoanaBanana, i like that idea to only bind one keyboard. Maybe the restrict to one keyboard and then announce to the user any other keyboards that have been restricted and let them decide to add them in.

Mice vs Keyboard gets so gray though because mice often are treated as keyboards at least in the windows world. Years back, there was an attack that happened via wireless mice that leveraged keyboard commands / api in the driver.