Modify qubes.InputKeyboard policy to disallow certain VMs

[Hainish]

General notes:

The current Qubes /etc/qubes-rpc/policy/qubes.InputKeyboard permits you to allow USB keyboard input to dom0, but not (afaict) to create exceptions to this rule.

For instance, I'd prefer that dom0 be able to use USB keyboard input unless I'm typing into my split-gpg VM. That way, I can use a USB keyboard, but if I start typing in my passphrase from the USB keyboard I will be able to see from pinentry that it is not accepting input, and hopefully stop typing, switching to my laptop keyboard.

This will help mitigate the risk of a malicious USB keyboard logging keystrokes while minimally affecting usability.

[marmarek]

The current Qubes /etc/qubes-rpc/policy/qubes.InputKeyboard permits you to allow USB keyboard input to dom0, but not (afaict) to create exceptions to this rule.

Actually the default policy do not allow USB keyboard at all.

For instance, I'd prefer that dom0 be able to use USB keyboard input unless I'm typing into my split-gpg VM. That way, I can use a USB keyboard, but if I start typing in my passphrase from the USB keyboard I will be able to see from pinentry that it is not accepting input, and hopefully stop typing, switching to my laptop keyboard.

This is unfortunately impossible in the current architecture. There is no way to distinguish at the policy level to where particular input even will be delivered. Keyboard (or any input device) is plugged in to the system, then X server takes the events and deliver to the currently focused application. So, as you can see, decision where the event will be delivered is much later than actual policy.

Also if we look at the problem from another side - GUI daemon (delivering events into VM), X server do not provide information which input device generated the event, so it isn't possible to filter it here either.

And even if that all would be possible, this doesn't stop malicious USB VM from injecting sequence of keystrokes to dom0 to change the configuration... And you probably want to allow interacting with dom0 applications, otherwise you wont be able to interact with, for example, window manager (Alt-tab etc), or Qubes Manager.

Somehow offtopic: IMHO much better solution for USB keyboard problem would be to have a piece of hardware plugged between USB keyboard and PC (based on https://github.com/robertfisk/USG?), to encrypt and integrity-protect the events. And then decrypt them in dom0 and check integrity protection, and only then pass them down to input devices stack. This should at least partially guard against malicious USB VM. It still will be able to perform timing based attacks to guess what you're typing - not sure how accurate such attacks are currently. Such device could introduce artificial delay (like - inject queued events every 50ms) to at least partially mitigate such attacks.

[marmarek]

The current Qubes /etc/qubes-rpc/policy/qubes.InputKeyboard permits you to allow USB keyboard input to dom0, but not (afaict) to create exceptions to this rule.

Actually the default policy do not allow USB keyboard at all.

For instance, I'd prefer that dom0 be able to use USB keyboard input unless I'm typing into my split-gpg VM. That way, I can use a USB keyboard, but if I start typing in my passphrase from the USB keyboard I will be able to see from pinentry that it is not accepting input, and hopefully stop typing, switching to my laptop keyboard.

This is unfortunately impossible in the current architecture. There is no way to distinguish at the policy level to where particular input even will be delivered. Keyboard (or any input device) is plugged in to the system, then X server takes the events and deliver to the currently focused application. So, as you can see, decision where the event will be delivered is much later than actual policy.

Also if we look at the problem from another side - GUI daemon (delivering events into VM), X server do not provide information which input device generated the event, so it isn't possible to filter it here either.

And even if that all would be possible, this doesn't stop malicious USB VM from injecting sequence of keystrokes to dom0 to change the configuration... And you probably want to allow interacting with dom0 applications, otherwise you wont be able to interact with, for example, window manager (Alt-tab etc), or Qubes Manager.

Somehow offtopic: IMHO much better solution for USB keyboard problem would be to have a piece of hardware plugged between USB keyboard and PC (based on https://github.com/robertfisk/USG?), to encrypt and integrity-protect the events. And then decrypt them in dom0 and check integrity protection, and only then pass them down to input devices stack. This should at least partially guard against malicious USB VM. It still will be able to perform timing based attacks to guess what you're typing - not sure how accurate such attacks are currently. Such device could introduce artificial delay (like - inject queued events every 50ms) to at least partially mitigate such attacks.

[andrewdavidwong]

This is unfortunately impossible in the current architecture.

Closing as "cantfix."

[andrewdavidwong]

This is unfortunately impossible in the current architecture.

Closing as "cantfix."