What is the proper way of having `rd.qubes.hide_all_usb` and still being able to enter LUKS password using USB keyboard?

User Support
,
1

What is a proper way to have rd.qubes.hide_all_usb and still being able to enter LUKS password using USB keyboard?

If one users sys-usb, the only major problem is exposing dom0 directly to USB devices during boot. That’s why the kernel parameter rd.qubes.hide_all_usb can/should be used.

But in this case it’s not possible to enter LUKS password during boot using USB keyboards. Considering PCs (not laptops) USB keyboard is almost the only option nowadays, so some proper way of workaround should exist.

What is recommended and proper way to solve this?

2

rd.qubes.hide_all_usb is used when the keyboard is not USB based because it hides all USB devices from dom0 at boot. In Qubes 4.1, the boot option usbcore.authorized_default=0 was introduced and uses USBGuard to only allow USB input devices at boot.

The Qubes documentation mentions these options and includes a section on using a USB controller specifically for keyboard and mouse devices.

I’m not sure you can use both rd.qubes.hide_all_usb and rd.qubes.dom0_usb at the same time.

1 Like
3

If you wish to use a USB keyboard to enter your LUKS passphrase, you cannot hide its USB controller from dom0. If you’ve already hidden that USB controller from dom0, you must revert the procedure by removing the rd.qubes.hide_all_usb option and employ an alternative strategy for protecting your system by physically disconnecting other devices during startup.

Qubes 4.1 only: You should also add the usbcore.authorized_default=0 option, which prevents the initialization of non-input devices. (Qubes ships with a USBGuard configuration that allows only input devices when usbcore.authorized_default=0 is set.)

USB qubes — Qubes OS Documentation

1 Like
4

Thank you, I read this piece of documentation several times.
Still it does not provide the answer for my question.

I was considering to add some exception (e,g, via kernel parameters?) like:

  1. Add exception for one PCI controller.
  2. Add exception for particular input device on particular PCI controller.
  3. Add exception for all input devices (e.g. keyboards) on this stage of boot, until sys-usb would be able to start.

So, you everybody thinks there is no solution?

If one has USB keyboard on Qubes OS, it is NOT possible to limit exposure of all USB devices to dom0 on boot?

5

Well, do you mean that it is supported on R4.2, too? Because documentation says it’s R4.1-only specific.

Is it working in R4.2 and docs are outdated/misleading?

6

If you want to separate one controller and keep it inside dom0, you will need to set usbcore.authorized_default=0 and rd.qubes.dom0_usb with your controller identifier. The excluded controller should contain the USB keyboard and mouse, which will work directly in dom0 without interacting with sys-usb input proxy service. Other USB devices won’t work with the USBGuard configuration unless they tell the system that they are input devices, which sometimes happens with weird devices.

If your goal is to hide all USB devices at boot except the keyboard and mouse, then setting usbcore.authorized_default=0 will be enough.

Yes, it was added in Qubes 4.1, and it still works today, even on 4.3-rc1.

2 Likes
7

@DVM Great answer, thank you! I missed that docs can be outdated and R4.1-only can mean R4.1 or later.

Before I mark your post as solution, can we please discuss these questions:

  • So, how reliable usbcore.authorized_default=0 is compared to having a separate PCI controller for keyboard?

  • As I see it, usbcore.authorized_default=0 looks like the best solution for average person with USB keyboard. So, is usbcore.authorized_default=0 set in R4.2+ by default instead of rd.qubes.hide_all_usb in case of USB keyboard?

  • What is =0 in usbcore.authorized_default=0? What are other values? Do you have any link to docs about it? Or should I search the project’s code?

Thanks again for fast and good answer.

8

It depends on your threat model. If you’re okay with your keyboard and mouse sharing a controller with other devices, then setting usbcore.authorized_default=0 is fine. However, if you want to isolate them, you can use a different controller and either keep it in dom0 with rd.qubes.dom0_usb or present it to sys-usb after LUKS unlocking.

The Qubes Installer automatically detects the use of a USB keyboard and adds the correct boot option. Check the file /etc/default/grub; it should include usbcore.authorized_default=0 if you have a USB keyboard or rd.qubes.hide_all_usb if you don’t.

This is a native kernel boot option that controls how the kernel handles USB devices:

# https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
usbcore.authorized_default=
                        [USB] Default USB device authorization:
                        (default -1 = authorized (same as 1),
                        0 = not authorized, 1 = authorized, 2 = authorized
                        if device connected to internal port)

USB devices are not authorized at boot when set to 0. USBGuard allows input devices manually at boot, so the keyboard and mouse can work until sys-usb takes over the controller(s).

1 Like
9

OK, so, it’s a upstream feature, not Qubes OS’s, got it. Thanks a lot all for replies.

1 Like