Justification for not enabling sys-usb-keyboard by default on a fresh Qubes OS install

General Discussion
#1

I’ve been re-reading the wonderful Qubes OS docs, because, you know, they’re so comprehensive and well-written (they actually are!); but it got me thinking.

On a fresh Qubes OS install, if a USB keyboard is detected, sys-usb is not created at all.

Is there any special reason for this?

————

The way I see it, under this setup:

  • All USB buses go straight into dom0
    • All HID devices are detected and accepted without question
    • All nob-HID USB devices also go straight into dom0
    • A malicious device with firmware that’s specifically crafted for Qubes OS could easily declare itself as a HID device and wreak havoc on your entire machine, including all your VMs
    • The user wouldn’t be notified of any such device suddenly pretending to be a keyboard
  • I’d imagine quite a lot of new users would get excited about Qubes OS, only to get frustrated when that none of their USB devices work out-of-the-box
    • Printers, game controllers, YubiKeys, etc. all go into dom0 and the AppVMs don’t even know they exist
    • This forum has quite a few threads about “Why don’t my USB peripherals work?”

Given all of the above, would it not make more sense to:

  1. Create a sys-USB by default
  2. Move all USB buses into it
  3. Have sys-usb dom0 allow by default for the qrexec policies
  4. Notify the user during the initial setup with a big dialog box stating the implications of this, with clear instructions on how to change these settings should they wish to

This would avoid the headache of having to create a sys-usb yourself, which can be a headache at the best of times for some users. It would allow new users to not erroneously think that they’re “missing drivers” for their USB devices.

It would also avoid the situation I found myself in of passing an AppVM that automatically starts on boot the USB buses containing the internal keyboard and trackpad of my laptop, forgetting to set the dom0 policies, and basically making it impossible to use the entire machine, and eventually rage quitting and reinstalling Qubes.

Not to mention; anyone with hardware containing a PS/2 keyboard would be unaffected either way.

Yes, having the policy of accepting USB keyboards by default does allow for rubber duckies, but so does putting them straight into dom0, so as far as I can see, there isn’t really any difference.

Or is there something I’m not taking into account?

Your thoughts?

4 Likes
Sys-usb on external SSD with USB keyboard + AEM
#2

You are sacrificing security for convenience.

It might be better to have the system fail, and force the user to implement the correct solution. You are given the user the illusion that sys-usb working, it would easily be a disservice to someone who doesn’t understand what this dummy sys-usb does. Without any negative feedback, the user might not replace the dummy sys-usb.

Should sys-usb be improved?, yes. Is the solution to disable sys-usb?, in my opinion, no.

I think you need to be very careful with watering down the product, Qubes OS is a product for the users who need the strong stuff.

1 Like
#3

My main argument was the fact that all USB buses were in dom0 by default. We go on and on about “making sure that nothing gets into dom0”, and yet we include a gaping hole in the form of the USB ports of the machine…

Does that not concern anyone else…?

I’d much rather have a BadUSB go into a dummy sys-usb, instead of going into dom0. Wouldn’t you?

My secondary argument was convenience :stuck_out_tongue_winking_eye:

#4

Except, with the USB keyboard, even if you have sys-usb, all usb devices (on the same USB hub) still have access to dom0 at least during boot (or not only that? I’m not sure), whereas the user might be thinking they’re safe.

Maybe there should be a big red text somewhere explaining it? Perhaps during the install. I agree that, in general, it’s still better than no sys-usb at all.

#5

Yeah, actually, you’re right. I knew there was something I was forgetting!

But if this is the case with or without a sys-usb, then why would you not want even a dummy one by default…?

Agreed.

#6

AFAIK this is not the case without a USB keyboard. This is the whole reason why you lock yourself out if you just add sys-usb while using a USB keyboard.

#7

I lost count how many times I did that when I started with Qubes OS years ago :laughing:

Well, maybe some kind of “pairing” or “whitelisting” for your keyboard so that it accepts keystrokes only from that particular device?

Maybe at boot, six random letters appear on the screen, and the user has to press those keys on that keyboard, and if they successfully do that, that keyboard becomes “trusted” enough to enter the LUKS password?

Then other keyboards could only be accepted with that trusted keybaord, like the way it is now…

#8

AFAIK this is not how the hardware works. All other USB devices on the same USB controller are not isolated. It should be safe to use a different USB controller for untrusted devices (if you have it!), otherwise you are risking to infect the controller with something dangerous.

#9

Challenge-response enumeration, maybe?

That’s true…

A feature that I wish was default in hardware design, but some people might have bought machine with only one…

I still think that there has to be a way to do this :slight_smile:

#10

Wouldn’t this still be really bad if the default policy is allow?

Maybe I’m misunderstanding something, but is what you are suggesting not similar to fixing file permissions with chmod 777 ?

#11

I’m talking about the qubes-rpc policy settings, allowing qubes.InputMouse qubes.InputKeyboard or qubes.InputTablet from one vm to another (including dom0).

That would allow passthrough of keystrokes into dom0, so that you can move your cursor and type things.

Yes, this would not stop a rubber ducky, but neither would having no sys-usb.

Ideally, PS/2 is preferable, but for hardware where this isn’t an option (which unfortunately is quite a lot of consumer devices), wouldn’t a qubes.InputKeyboard - sys-usb dom0 allow policy with a massive in-your-face explanation and warning be better than just putting the entire bus into dom0?

Not only would USB peripherals not go into any VM (convenience penalty), but if you have an infected printer, for example, that’s now got unrestricted access to dom0! (security penalty)

So now you’re pwned and you can’t print your documents :stuck_out_tongue:

I guess what I’m saying is that if I’m going to be pwned either way, I’d much rather be able to print stuff, than to be told that it’s “more secure” for me to keep my printer in dom0…

#12

I’ll give you an example with some hardware that I have

The GPD Pocket 3.

  • It has an accelerometer, and I have rigged it to auto-rotate the screen to portrait/landscape when tilted (Qubes OS in tablet mode with a stylus and xvkbd is actually surprisingly usable…)
    • This is stuck in dom0 (for now)
  • It has a touchscreen which allows finger and stylus input
    • These are stuck in dom0 (for now)
  • It doesn’t have a PS/2 keyboard and mouse, only USB
    • These are in sys-usb
    • qubes.InputKeyboard = sys-usb dom0 allow
    • qubes.InputTablet = sys-usb dom0 ask,default_target=dom0
    • qubes.InputMouse = sys-usb dom0 ask,default_target=dom0
  • rd.qubes.hide_all_usb is not present in /etc/default/grub, because that basically makes it impossible to get past the LUKS decryption screen

This allows the LUKS password to be entered with the internal keyboard directly connected to dom0, but then sytemd starts sys-usb and takes it off dom0, and sys-usb gives it back to dom0 via qrexec.

To the end user, this appears to get the same end result: You can use your USB keyboard like normal.
But it has one important difference: You can use your printer too!

Yes, the machine will unfortunately always trust anything declaring itself as a keyboard (until maybe qrexec receives an upgrade), but for hardware like this, this vulnerability exists regardless of the existence of sys-usb.

So, in this case, how can a new user to Qubes OS (or even a veteran user, for that matter) see any benefit in not having a sys-usb like I’ve described?

If the vulnerability is going to exist no matter what, you might as well have some nice functionality, no…?

1 Like
#13

There’s a lot of misinformation on this thread.

  1. Qubes OS handles USB controllers assigned to a USB VM before the VM start by assigning them to a no-op kernel driver named ‘pciback’. It cannot do anything before, i.e. what happens during the time your BIOS or your bootloader has control, is up to them and may still get you compromised.

  2. If you have USB devices in dom0, Qubes OS may be running usbguard (see systemctl status usbguard). It’s a daemon that disallows devices to be attached to dom0. Someone may still attempt to compromise your USB controller via hardware-specific attacks though, yes. USB attacks targeting the dom0 kernel should be mostly mitigated though. That feature was introduced in 4.1 and may not be enabled on all machines (depends on your kernel arguments, see the Qubes USB doc for details).

  3. If and only if neither usbguard nor USB VMs are enabled for a particular USB port, that port can rather easily compromise you with a malicious USB device. You’ll see a warning such as “Unrestricted USB” during every Qubes OS boot.

3 Likes
#14

That’s how every thread should be. Knowledge is power :wink:

@tripleh, those are definitely all valid points from a security perspective, and absolutely awesome design by the devs, but I’m not talking about this from a security perspective. That’s already been talked to death in this forum :slight_smile:

I’m imagining being a user who’s new to Qubes OS, and has all these USB peripherals that they like to use. Chances are, the new user’s hardware won’t have a PS/2 keyboard (let’s assume theyre trying to install it on Apple hardware, or the super-thin, barebones laptops that seem to be all the rage these days…), therefore the current installer won’t give them a sys-usb (or even put their USB controllers into sys-net), so none of their peripherals will “work” out-of-the-box.

If new users have a good first experience, then they’re more likely to stick with Qubes OS. And I have a feeling that this can be a massive turn-off or even a deal-breaker for some new users…

#15

It would require Qubes OS to automatically decide which USB controllers to assign to sys-usb. That’s hard as it depends on how the user uses his/her machine (e.g. will s/he move the USB keyboard to a different port? What about that USB sound card?). And that’s why Qubes OS sticks with the manual process. It would frustrate users a lot more if they’d get an incorrectly configured sys-usb from the installation media.

Btw with usbguard there’s a good in-between path for those users. Some protection, but the USB keyboard remains usable. That may become the new default for those users sooner or later.

#16

So then why not just assign all of them to sys-usb? What’s the logic behind that?

Seriously, what is the difference between dom0 with usbguard and sys-usb with keyboards accepted by default?

The only difference I can see is that you can use peripherals in one, and you can’t in the other. :face_with_diagonal_mouth:

Right…?

Should that matter? If they all were in sys-usb, then sys-usb would take care of all of that…

Wouldn’t it…?

I have a laptop where the internal sound card is a USB one (lazy hardware design, but it is what it is, and I can’t change it), so I run a script at boot to pass it through from sys-usb to sys-audio, along with the bluetooth usb controller. It works quite well. The volume controls on the keyboard work, too.

How would what I’m suggesting create an “incorrectly configured sys-usb”? The current salt state sys-usb-keyboard already does this perfectly. I’ve used it on 22 different laptop models that didn’t come with sys-usb from first boot, and they all work like a charm. It just isn’t automated or the default, which it really should be.

I genuinely don’t see any negative impacts to that being the default configuration for new installs, and allow the user to turn that off if they wish (but I would honestly be surprised if anyone would actually remove their sys-usb, I’m having difficulty thinking of a scenario where it would actually be beneifical…).

No?

usbguard is a fantastic piece of software. It really is. I look forward to seeing it progress as time goes by. But I still fail to see how that will get your printer passed into a Qube so you can print your report by 9am to give to your boss…

So I think my initial point still has some validity… :slight_smile:

#17

Ah, you’re arguing about the keyboard & mouse forwarder. I didn’t think of that.

However it also has security disadvantages to have all USB devices in one sys-usb. After all any malicous USB device in sys-usb will then get full control over your mouse & keyboard - assuming both are USB. IIRC the Qubes OS doc mentions that, too.

“All in one” != compartmentaliztaion.

2 Likes
#18

Definitely. 100%.

Definitely true.

It would be lovely to have all hardware have a dedicated USB controller for HID devices (if anyone would mandate that, it would be the EU :stuck_out_tongue_winking_eye:), but that doesn’t help the people who bought a potato laptop before they even knew about the existence of Qubes OS (no offence to anyone who has one, potatoes are delicious :grin:), decide to “give it a try”, and then are like “how come I can’t see my printer/USB tablet/wifi dongle/YubiKey/<insert-generic-USB-device-here>?!??! Qubes OS is absolutely terrible. I’m never using it again! It’s ‘broken’….”

#19
2 Likes
#20

Thank you, @marmarek and @fsflover :grin: