Hardened option for single USB keyboard

The problem you're addressing (if any)

Currently, on systems which can use only USB keyboards, it seems possible to have unrestricted number of such USB keyboards that are automatically allowed to connect to dom0 due to /etc/qubes-rpc/policy/qubes.InputKeyboard permissive policy. This makes it possible a malicious USB device (e.g. a USB memory stick) to represent itself as a keyboard, do its mischief, then switch back to being a non-keyboard.

Using usbguard inside sys-usb to allow only specific predefined keyboards is a possibility, however it might result in a situation when the user gets locked out of the system. Example: The user has only one physical keyboard and whitelists it in usbguard rules. If the keyboard hardware stops functioning (e.g. the keyboard is physically damaged), the user will be compelled to replace it with another. However, since the new keyboard will not be whitelisted, the user won't be able to access the system through it, regardless of the fact that it is a good (non-malicious) device.

The solution you'd like

Provide an option (perhaps even enforced by default) which allows the user to restrict the number of possible USB keyboards on the system to 1 (one) at a time.

The value to a user, and who that user might be

The proposed solution would make it impossible for a malicious device to act as described, as a second keyboard will be denied. The only way to use another USB keyboard would be to physically disconnect the first one, then connect another. That must also be documented properly.

Possible caveat

I don't know if that is possible (there are some reports), but just for extra consideration:

If for some reason (e.g. a driver bug, power related issues or other) the malicious USB device is able to cause the original keyboard to (appear to) disconnect or simply "sneak in" while the original good keyboard is actually disconnected, the proposed solution will not work per se - the malicious device may still connect as a keyboard and accomplish the described attack, and during that period the actual keyboard will be blocked. To prevent such possibility, additional possible measures to the solution might be:

Enable any newly connected USB keyboard only after reboot

In this way, even if a temporary disconnect happens, no other device would be able to take over a running the system, because to accomplish an attack the malicious device would have to cause a reboot of dom0 through sys-usb, which seems impossible in Qubes OS (at least not without a serious security bug).

UI for easy whitelisting of newly connected keyboards (using usbguard rules in sys-usb)

Without other input device (e.g. at least a mouse able to click and confirm the newly connected keyboards), a possibility for user input might be the power button of the system. A service like acpid may be used to monitor for events. Example usage:

A new keyboard is connected. The UI dialog shows up and asks for confirmation. The user is required to press the power button of the system to activate the new keyboard, after which it gets whitelisted in /etc/usbguard/rules. The acpid service may probably run in a separate VM (sys-acpi), thus making it impossible for a malicious device to attack both sys-usb and sys-acpi. Having sys-acpi may even provide extra security, e.g. the number of presses within a period of time might be configurable, e.g. "must press 3 times within 10 seconds", and may serve as a "password" for allowing new USB devices.

Additional notes:

As by default passwordless root is enabled in VMs, whitelisting devices in sys-usb itself may turn out vulnerable. I don't know what inter-VM communication mechanism for this may be suitable but it seems better to isolate the "credentials" of devices - have another VM store and verify if a device is whitelisted, then report the result back to sys-usb.

This may be obvious, but a "only one keyboard" plan should be able to select the correct keyboard. I.E. not accept the fake keyboard, instead of the users keyboard.

For example, a IPMI "feature" can sometimes try to create a fake USB keyboard in your own system, those that use a USB keyboard and are booting get the UI dialog showing up and asks for confirmation. They confirm yes, and the IPMI virtual keyboard was just added instead of thier actual USB keyboard.

So when the UI dialog pops up, maybe flash the numlock LED and ask the user if the numlock LED is flashing on a keyboard they want to use, to hit the ACPI power button sequence.

Of course this raises the question of if connecting to the sys-usb keyboard enough to flash the num lock has any security issues of its own. :)

Also: while your planning your "managing your computer through power button taps" idea, you may want to cover the case of accidentally shutting down the sys-usb qube, which apparently happens enough that it got discussion on the fourm: https://forum.qubes-os.org/t/quick-quality-of-life-improvements/23380/17

possibly even handle resetting the sys-usb qube?

Just some ideas

[Note: i don't use a USB keyboard, so the issue actually doesn't effect me.]

This may be obvious, but a "only one keyboard" plan should be able to select the correct keyboard. I.E. not accept the fake keyboard, instead of the users keyboard.

Yes. The correct keyboard is manually whitelisted by the user. Even if you have 2 correct ones, only one can be active.

For example, a IPMI "feature" can sometimes try to create a fake USB keyboard in your own system, those that use a USB keyboard and are booting get the UI dialog showing up and asks for confirmation. They confirm yes, and the IPMI virtual keyboard was just added instead of thier actual USB keyboard.

I have zero experience with IPMI. AFAIK, it works independently of the OS, so I don't know if it can be allowed/prevented by a running OS. Even if the OS cannot block it (i.e. IPMI can "plug" an fake USB keyboard at any time), with the current feature (authorization through power button presses) it would still be impossible to whitelist such a keyboard, so it is probably not an issue. Then question is - can a PS/2 keyboard be "plugged" through IPMI, with all the implications of that, which I guess is a separate issue.

So when the UI dialog pops up, maybe flash the numlock LED and ask the user if the numlock LED is flashing on a keyboard they want to use, to hit the ACPI power button sequence.

That is an interesting idea. Some things which may need consideration:

Can IPMI cause flashing of the LEDs of the local keyboard? The result may be - the LEDs are flashing locally but the user is tricked to confirm the fake IPMI USB keyboard, thus unlocking the possibility for a remote attack.
Can IPMI simulate a press of the ACPI power button? IIUC, this is possible:

https://www.unix.com/man-page/centos/1/ipmitool/

"or by simulating a power button press"

Then the question becomes whether a simulated press can be distinguished from actual physical one.

The point is: If such remote attacks are possible, regardless of the OS, there isn't really anything that can be done on OS level. The only solution is to disable IPMI on a lower level/ring.

[Note: i don't use a USB keyboard, so the issue actually doesn't effect me.]

Considering how computers "evolve", that may be just a matter of time. Unfortunately.

Then question is - can a PS/2 keyboard be "plugged" through IPMI, with all the implications of that, which I guess is a separate issue.

That is a interesting question

Can IPMI simulate a press of the ACPI power button? IIUC, this is possible

Probably. One of the major reasons for having IPMI is to be able to remotely

Then the question becomes whether a simulated press can be distinguished from actual physical one.

A even more interesting question.

My point was not about defending against IPMI though. My point was that during installation, during the initial whitelisting, it'll detect 2 keyboards and need to say something to the effect of: "It looks like you have more then one USB keyboard plugged in. If you do not have more then one keyboard currently plugged in, then something is simulating a USB keyboard. Malicious USB devices can simulate a keyboard as a way of attacking your system. If it's a malicious device you'll probably want to stop now and address that. Alternatively, it could be a device that is not malicious (but still a device you will probably want to disable anyway). For example IPMI is built into many motherboards, which is a feature that will emulate a USB keyboard for the purposes of the computer owner being able to remotely control the computer.

The USB names of the devices are:

{blah blah blah}

If you want to continue now, I'll flash the num lock on the first keyboard a certain number of times, and flash the num lock on the second keyboard a different number of times,

watch the keyboard you want to use, and watch how many times the num lock flashes, then tap (I.E. press and then quickly release) the power button that number of times. "

but hopefully find a way to say it in one sentence, cause no one wants to read that much during a install. :)

My point was that during installation [...]

IIUC, there are 3 "environments" to consider:

(A) During installation (B) After installation during boot (C) While the OS is loaded and running

When opening the current issue, I envisioned only (C) and IPMI should probably be considered.

As for the others:

(A)

AFAIK, IPMI requires network. Qubes OS disables networking during installation. Doesn't that block IPMI too?
One can unplug the Ethernet cables during OS installation. That eliminates IPMI.
One cannot unplug soldered wireless adapter on motherboard. If IPMI cannot be disabled by the installer or in BIOS settings, such hardware should probably be considered inappropriate in the first place (unless used in a Faraday cage).

In short, for (A) it seems more appropriate to eliminate IPMI, rather than increase the number of interesting questions. :)

(B)

https://qubes-os.org/doc/usb-qubes/#how-to-hide-usb-controllers-from-dom0

If IPMI is enabled (and impossible to disable) during the boot process, maybe it can do some mischief while the OS hasn't loaded completely. I don't know how feasible that is though.

QubesOS / qubes-issues