Set rd.qubes.hide_all_usb when configuring default USBVM

[rootkovska]

We should be ensuring that rd.qubes.hide_all_usb (see #861) is passed to the Dom0 kernel by default if the user chose to have a "USB-holding qube" in firstboot. Except when we detect that the user has a USB-connected keyboard (which we already do), as then the above would prevent the user from entering the LUKS passphrase (even if later qubes.InputKeyboard was used). Still, the user would have a chance to enter GRUB menu and remove that option, in case we wrongly assumed USB keyboard is not used.

How to test if this works

Connect external USB keyboard while booting your system and check if you can enter LUKS passphrase. If you can, this means your Dom0 kernel has enabled the USB controller(s). And so we want this not to happen, so we want the external keyboard to not work during LUKS prompt.

Rationale

One might argue passing this option might to not provide for a significant security improvement, because any sane user is expected to detach any external USB devices when rebooting the system anyway. While this might be true (or not ;) this solution doesn't address the problem of attacks coming from hypothetically malicious or compromised internal USB devices, such as cameras, cellular modems, etc. (but likely not USB controllers as these are currently part of the processor package...). By hiding all the USB controllers from Dom0 we prevent Dom0 from parsing the USB device information, loading corresponding drivers, and potentially performing millions other actions we don't want it to do in response to input coming from the USB devices.

Still, one might argue that even though we might prevent Dom0 from interacting with potentially untrusted internal USB devices, we can't prevent the BIOS and the bootloader (e.g. GRUB) from doing this. Well, this might, or might not be true, depending on the specific BIOS that is used. I think we can imagine a BIOS that could be configured to not enumerate, configure nor use any USB devices (coreboot comes to mind). In that case, it would make perfect sense that Qubes Dom0 continue this prudent behavior.

Also, we could theoretically use TXT SENTER to launch Qubes (e.g. via AEM2), which should also prevent such early-boot USB attacks from happening. Unless they succeed in exploiting the BIOS and later get a way into the SMM, which would allow them to survive the SENTER (unless the platform implements STM, which however I highly doubt).

IOW, I think it's worth enabling this option by default. FWIW, I just tested it on the latest 3.2-rc1 and it seems to work fine.

[andrewdavidwong]

One might argue passing this option might to not provide for a significant security improvement, because any sane user is expected to detach any external USB devices when rebooting the system anyway.

As I argued on the MLs a few years ago: I don't think this is reasonable in the case of a large desktop computer with a dozen (or more) USB devices plugged in, where the user would have to physically move a large, heavy computer case in order to access the back panel to unplug the dozen (or more) USB devices every time he or she has to reboot.

[andrewdavidwong]

One might argue passing this option might to not provide for a significant security improvement, because any sane user is expected to detach any external USB devices when rebooting the system anyway.

As I argued on the MLs a few years ago: I don't think this is reasonable in the case of a large desktop computer with a dozen (or more) USB devices plugged in, where the user would have to physically move a large, heavy computer case in order to access the back panel to unplug the dozen (or more) USB devices every time he or she has to reboot.

[marmarek]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-3.2.2-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-3.2.2-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-3.2.2-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-3.2.2-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update