Whenever I attach a wireless USB mouse it connects automatically to dom0.
This USB does not shows on the tray widget.
I tried to deny InputMouse qubes policy with:
“”"
#sys-usb dom0 ask,user=root,default_target=dom0
sys-usb dom0 deny
$anyvm $anyvm deny
“”"
And still it connects to dom0.
How can I have some control of this behavior? I was hoping to have some system policy to control this automatic attachments and avoid installing usbguard.
Any help will be appreciated.
Thanks
simply read and follow these step.
Hello, can you be more specific, please?
from the documentatio I read:
“With a USB qube, every time you connect an untrusted USB device to a USB port managed by that USB controller, you will have to attach it to the qube in which you wish to use it (if different from the USB qube itself”
you will have to attach it to the qube in which you wish to use it. (This is not happening) it’s connecting automatically to dom0
From the mice section it says:
“If you want to attach the USB mouse automatically anyway, you have to edit the qubes.InputMouse policy file in dom0, located at:”
This is what is happening to me by default. IT was not supposed. I edited the RPC policy to force a deny policy, and even after that, the mice connects automatically to dom0 without my authorization.
Also, after that policy modification, a notification appears on the screen when booting sys-usb saying that mice has been denied. But it’s wrong, since this policy is not being enforced.
From the documentation, it simply tell you that.
You could create a sys-usb vm to handle your usb controller.
have you create sys-usb vm ?
how you create the vm ?
are you sure your usb controller have been passthough to sys-usb ?
if intel, did you add no-strict-reset option ?
have you create sys-usb vm ? Yes
how you create the vm ? sudo qubesctl state.sls qvm.sys-usb
are you sure your usb controller have been passthough to sys-usb ? yes, 3 pci devices attached and usb devices are listed inside sys-usb qube with lsusb
if intel, did you add no-strict-reset option ? yes, the 3 pci devices have - “sys-usb (no-strict-reset=true)”
Try to set only
$anyvm $anyvm deny
in your InputKeyboard policy and/or hide all usb controllers from dom0, with
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes.hide_all_usb"
in your grub and reboot?
leaving only “$anyvm $anyvm deny” doesn’t work.
can’t add “rd.qubes.hide_all_usb” or else I will not be able to enter Luks Password.
Are you sure you’re only passing the USB controller and -NOT- the PCIe bridge above it ?
I couldn’t fully understand what you mean by “not the pcie bridge”, but this are the PCI devices attached to sys-usb:
“”"
dom0:00_0d.0 USB controller: Intel Corporation Tiger Lake-H Thunderbolt 4 USB Controller sys-usb (no-strict-reset=True)
dom0:00_0d.2 USB controller: Intel Corporation Tiger Lake-H Thunderbolt 4 NHI #0 sys-usb (no-strict-reset=True)
dom0:00_14.0 USB controller: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 xHCI Host Controller sys-usb (no-strict-reset=True)
“”"
Only those devices are available to sys-usb.
Also, I made other tests. I deleted and created the sys-usb VM.
When the popup to allow the mouse appears, I didn’t click anything and plugged the USB mouse, and it is working, which means that those policies are not even working.
And I’m sure the mouse is connected inside sys-usb, because I can red this inside sys-usb:
“”"
Bus 004 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
“”"
Hmm, sorry but I can’t understand from what you posted, rather post a lspci -vt from dom0.
It’s fine to edit the most part if you’re paranoid, just keep the partial full tree to your USB controller (I mean the starting + of the following output should be directly attached to the root, 0000:00).
Here is some example output of mine :
+-09.1-[25]--+-00.0 Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function
| +-00.2 Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor
| \-00.3 Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller
Are you using a IOMMU ?
Hmm, nevermind, I didn’t see the last paragraph … If your mouse is seen inside sys-usb, it means it should work, and isn’t a PT issue >.<
Or you could try to install the gpm package in sys-usb and VNC-connect to it, and see if it works in the console ?
Last thoughts ^^
Are you sure there’s no usbctrl-attach or usbdev-attach that happened ? Try xl usb-list sys-usb.
If you xenstore-ls -f | grep "12:00" (with 12:00 being the PCI id of your USB cotnroller), do you see the device ?
I tried xl usb-list sys-usb and no output, is this right?
about xenstore-ls -f I get:
`
[anon@dom0 ~]$ xenstore-ls -f | grep “0d.0”
/local/domain/0/backend/pci/5/0/key-1 = “0000:00:0d.0”
/local/domain/0/backend/pci/5/0/dev-1 = “0000:00:0d.0”
/libxl/5/device/pci/0/key-1 = “0000:00:0d.0”
/libxl/5/device/pci/0/dev-1 = “0000:00:0d.0”
[anon@dom0 ~]$ xenstore-ls -f | grep “0d.2”
/local/domain/0/backend/pci/5/0/key-0 = “0000:00:0d.2”
/local/domain/0/backend/pci/5/0/dev-0 = “0000:00:0d.2”
/libxl/5/device/pci/0/key-0 = “0000:00:0d.2”
/libxl/5/device/pci/0/dev-0 = “0000:00:0d.2”
[anon@dom0 ~]$ xenstore-ls -f | grep “14.0”
/local/domain/0/backend/pci/5/0/key-2 = “0000:00:14.0”
/local/domain/0/backend/pci/5/0/dev-2 = “0000:00:14.0”
/libxl/5/device/pci/0/key-2 = “0000:00:14.0”
/libxl/5/device/pci/0/dev-2 = “0000:00:14.0”
`
I was thinking about this, could it be something related with this being an unified dongle, capable of mouse and keyboard, and qubes thinks that this may have a keyboard and accepts it automatically, even if there is already a usb keyboard attached on sys-usb?
what policy have you change?
normally that if you run sudo qubesctl state.sls qvm.sys-usb you should’nt be able to use keyboard to enter luks password, or perhaps you already change the policy and delete the kernel parameters ?
Also try to remove dom0:00_14.0 from sys-usb, restart Qubes and try it.
You’r right. I did a time ago. The one that I used recently to recreate the sys-usb was: ```
qubesctl state.sls qvm.usb-keyboard
Removing dom0:00_14.0 removes all the usb devices. Which means that usb devices are now connected to dom0. The other 2 PCI devices are just for Thunderbolt, which don’t have any device connected.
Sorry, I meant to separate… but 51lieal I think gave you the hint combined with that it might be unified dongle. Disable keyboard and check your mouse, maybe?
Or try this?
Tested today with an USB mouse(no unified dongle), and it doesn’t connect automatically. Which is the expected behavior.
I guess that qubes detects that the Logitech Unified Dongle may have a keyboard and connects it to dom0.
Internally how qubes redirects the input devices to dom0? Does it connects the USB device directly to dom0 or is it a kind of bridge that redirects the HID devices from the VM to the dom0?
Should we suggest a new feature to qubes team to detect this kind of edge cases?
I don’t know what version you’re using, but policies syntax have changed, see RPC policies | Qubes OS
The new format uses @, not $