I edited etc/quabes-rpc/policy/qubes.InputKeyboard so it says
sys-usb dom0 allow
$anyvm $anyvm deny
(I had deleted the second line, but then put it back. I may have mistyped it when I put it back, I didn’t back it up before the edit.)
I am also using a USB mouse that is ergonomic.
Although I have an ethernet port in my system, I have been using a USB ethernet because I thought this might reduce vulnerabilities of Intel ME. My thinking was that ME often relies on Internal components, and if it’s having to search for external devices to access things, and with Qubes, it may reduce ME as a vulnerability. (One day I’ll afford System76.) This is likely flawed reasoning.
There are different USB controllers in my system, and I know I could try to isolate them. The USB ethernet is on a different controller.
I do not understand if what I did now with giving the USB keyboard dom0 access allows someone who has hacked the sys-usb hub via the ethernet which is attached to access dom0 right away or if sys-usb is only letting the keyboard and mouse have access. This feels like really bad isolation to me, and when I read the instructions for making this only apply to 1 USB hub, I didn’t understand the instructions, even after trying to read support threads.
Am I making a mistake by doing things this way? I also think that as a Qubes user, who is sometimes downloading things from Qubes-specific IP addresses, I am at a higher risk of attack because people may think a Qubes system has more valuable information. Although the IP addresses being contacted are likely secure, these days Internet communication passes through so many large players that use DPI and other tools and I don’t trust my infrastructure, which is part of why I like Qubes.
Is it worth it to try to apply this only to the bus controller? Should I stop using the USB ethernet? Am I looking at this the right way?
My advice would be cloning the existing sys-usb (let’s call it “usb-keyboard” qube) and attach the keyboard to that and then pass it to the dom0. Check my thread on this:
If sys-usb is compromised, then there’s no practical difference between the two. Dom0 cannot tell whether keystrokes are coming from a malicious process running in sys-usb or your physical keyboard, since that keyboard has to “go through” sys-usb in order to reach dom0.
I wouldn’t assume that. However, if it worries you, simply use Tor or a VPN for such traffic.
So based on that, it seems like it would be better to attach my ethernet to the system’s internal ethernet to avoid such a thing.
I changed back the qubes.Inputkeyboard to $anyvm $anyvm deny. It seems like having sys-usb have access to dom0 is incredibly risky. But I also like using a USB mouse.
I may have multiple usb controllers, could I get around this?
I am nervous, possibly illogically, about plugging an ethernet directly into an onboard ethernet that likely is more directly wired the motherboard, making it more accessible by Intel ME, which I think is nefarious. ME is already aware of this ethernet and the WiFi card that I pulled out and destroyed based on the motherboard schematics and the ME version, most likely. I am just concerned I am giving ME easy access to the internet.
I read this before and wasn’t sure my intelligence level/working memory was enough to understand or implement it.
It looks like on the 16th post you may have elucidated the instructions in a way I might be able to understand. Can I just start at the 16th post?
For my USB template, I use a fedora minimal template that I made disposable.
On step 1:
Clone the existing sys-usb qube’s templateVM using the Qube Manager GUI and name it “d11m-usb-keyboard” (d11m is my short-hand notation for (m)inimal (d)ebian (11) qube templates).
I have a minimal fedora usb template, then I have a disposable template based on the fedora minimal usb template. What am I cloning or changing? Also, since I think I’m modifying which controllers are attached, does that affect how I do this?
Also, is this the proper step at which to start this? I am very weary about having my usb ethernet plugin having access to dom0. It seems pretty stupid, and I already did it briefly so I should probably do a fresh reinstall at some point.
qvm-pci | grep “USB controller” it shows 3 controllers listed. I also have three USB ports. I am unsure if this indicates that I have 3 controllers. One controller is made by a graphics card company, which I don’t understand.
I have no idea, but in my experience, the odds are slim-to-none that a mainstream computer natively has three separate USB controllers for each of its three USB ports.
-Intel USB 3.1 xHCI Host controller
-NVIDIA USB 3.1 Host Controller
-Intel Thunderbolt 3 USB Controller
I created multiple USB qubes and attached each controller to each qube. All three of my USB ports are enabled when I attach the first controller, Intel USB 3.1 xHCL controller, although the devices are shown on different buses.
Does this mean I really only have 1 USB controller? If so, what are the other USB controllers used for?
The NVIDIA controller probably is because I have a NVIDIA graphics card. I have also not installed any special NVIDIA graphics drivers for Qubes. Is that something I should do? I don’t know if I am using a generic graphics driver or a NVIDIA graphics driver.
Okay, I just did a test. I have three USB “devices” in my sys-usb’s Devices tab, so I created three sys-usbs and assigned one to each, then I tried plugging devices into each physical port to see which sys-usb they showed up in. The result is that all the physical ports except for the Thunderbolt port connected to the same sys-usb. I’m not sure exactly what this means, but it seems like maybe my device (Darter Pro / darp8) actually has two separate USB controllers.
I suspect my situation is similar (I’m on an Intel NUC 11). It seems like a horrific waste to use thunderbolt for USB keyboard and mouse just to get them on a separate controller!
This is why it is important to identify the controllers and their
associated ports.
On some machines, there could be 2 controllers allocated to a single
port, and controllers for no ports. The documentation
does not mention these cases.
I’m still not quite sure I understand. Would you be willing to add to the documentation, either by opening a PR or providing the information here (which I can then add to the doc for you)?