Enhancement: input proxy and Qubes policy argument

[Rudd-O]

It would be ideal if the USB ID of the device was used to form an RPC argument that the USB qube can send to dom0, when connecting a device.

That way, we can have a policy per device. Say someone connects a wiggler or a foreign keyboard — if that happens, then the default deny policy is triggered and, bam, no device appears in dom0.

Thanks!

[marmarek]

Any kind of USB ID could be easily spoofed by both USB device and USB VM. We can't do much about USB device. Lets thing about USB VM - we have two cases:

1. USB VM being compromised - in this case, adding USB ID to RPC argument doesn't add much - it's about USB VM asking dom0 "please, deny/allow this call", which in case of compromised USB VM would always choose "allow" (and pass "correct" USB ID, for example extracted from logs).
2. USB VM not being compromised - in this is also asking dom0 "please, deny/allow this call", but if USB VM is not compromised, it can do all of it itself and not even trigger qrexec call at all.

So, implementing this is mostly where to put configuration (qrexec policy in dom0 vs some config in USB VM). And in fact IMO putting it into USB VM could have additional benefit - do not even load drivers for "unwanted" devices, reducing attack surface of USB VM from thousands of USB drivers, to just few of them. There are already few implementations of it: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev.

[marmarek]

Any kind of USB ID could be easily spoofed by both USB device and USB VM. We can't do much about USB device. Lets thing about USB VM - we have two cases:

1. USB VM being compromised - in this case, adding USB ID to RPC argument doesn't add much - it's about USB VM asking dom0 "please, deny/allow this call", which in case of compromised USB VM would always choose "allow" (and pass "correct" USB ID, for example extracted from logs).
2. USB VM not being compromised - in this is also asking dom0 "please, deny/allow this call", but if USB VM is not compromised, it can do all of it itself and not even trigger qrexec call at all.

So, implementing this is mostly where to put configuration (qrexec policy in dom0 vs some config in USB VM). And in fact IMO putting it into USB VM could have additional benefit - do not even load drivers for "unwanted" devices, reducing attack surface of USB VM from thousands of USB drivers, to just few of them. There are already few implementations of it: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev.

[andrewdavidwong]

So, implementing this is mostly where to put configuration (qrexec policy in dom0 vs some config in USB VM). And in fact IMO putting it into USB VM could have additional benefit - do not even load drivers for "unwanted" devices, reducing attack surface of USB VM from thousands of USB drivers, to just few of them. There are already few implementations of it: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev.

Does this mean that we do want to keep this issue open in order that this might get implemented at the USB VM level, or do we want to close this because it's beyond the scope of Qubes to implement such a thing at the USB VM level?

[andrewdavidwong]

So, implementing this is mostly where to put configuration (qrexec policy in dom0 vs some config in USB VM). And in fact IMO putting it into USB VM could have additional benefit - do not even load drivers for "unwanted" devices, reducing attack surface of USB VM from thousands of USB drivers, to just few of them. There are already few implementations of it: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev.

Does this mean that we do want to keep this issue open in order that this might get implemented at the USB VM level, or do we want to close this because it's beyond the scope of Qubes to implement such a thing at the USB VM level?

[Rudd-O]

Let's chat about case (2) a bit more in depth.

Let's suppose the VM is not compromised.

If it is not, then allowing me (the user) to say Yes to all to a specific mouse or keyboard, while blanket denying all other devices, is already a very useful feature.

I agree that, if the VM is compromised, this feature very much obviously does not help.

But it adds to the usability of the common use case (when the VM is not compromised).

I agree, however, that the feature could also be implemented directly in the input proxy of the USB VM, as filter for devices we want to plug into dom0. It's just that, frankly, it seems far simpler and more straightforward to leverage the argument in the RPC call.

[Rudd-O]

Let's chat about case (2) a bit more in depth.

Let's suppose the VM is not compromised.

If it is not, then allowing me (the user) to say Yes to all to a specific mouse or keyboard, while blanket denying all other devices, is already a very useful feature.

I agree that, if the VM is compromised, this feature very much obviously does not help.

But it adds to the usability of the common use case (when the VM is not compromised).

I agree, however, that the feature could also be implemented directly in the input proxy of the USB VM, as filter for devices we want to plug into dom0. It's just that, frankly, it seems far simpler and more straightforward to leverage the argument in the RPC call.

[jpouellet]

Considering the case of someone with internal keyboard attached via USB, where sys-usb is not compromised and you only want to whitelist input-proxy to only the internal keyboard, then depending on what we choose to use as the device identifier argument an attacker wishing to get keyboard access to dom0 may be forced to correctly guess some fields (many of which are unique per device) which together amount to enough bits to be improbable unless it's a targeted attack and you've posted verbose dmesgs online or such.

Furthermore, if you leave the policy as "allow" for your internal one and "ask" for others, you would know something's wrong well before an attacker would be able to brute-force the correct ID.

[jpouellet]

Considering the case of someone with internal keyboard attached via USB, where sys-usb is not compromised and you only want to whitelist input-proxy to only the internal keyboard, then depending on what we choose to use as the device identifier argument an attacker wishing to get keyboard access to dom0 may be forced to correctly guess some fields (many of which are unique per device) which together amount to enough bits to be improbable unless it's a targeted attack and you've posted verbose dmesgs online or such.

Furthermore, if you leave the policy as "allow" for your internal one and "ask" for others, you would know something's wrong well before an attacker would be able to brute-force the correct ID.

[jpouellet]

Yes, I agree it's obviously not perfect, but when your hardware forces the alternative to be putting your whole usb controller in dom0, or using the input proxy without trying to authenticate the particular keyboard at all... well... I'd prefer this.

@marmarek makes a very good point about wanting to reduce the number of USB drivers loadable on demand in sys-usb by someone fuzzing your external port or something, but I see that as an orthogonal issue.

[jpouellet]

Yes, I agree it's obviously not perfect, but when your hardware forces the alternative to be putting your whole usb controller in dom0, or using the input proxy without trying to authenticate the particular keyboard at all... well... I'd prefer this.

@marmarek makes a very good point about wanting to reduce the number of USB drivers loadable on demand in sys-usb by someone fuzzing your external port or something, but I see that as an orthogonal issue.

[Rudd-O]

Excellent points. What I had in mind, essentially. This may need work on the policy plus argument bug , but that work was longstanding anyway.

…

On May 26, 2017 9:37:12 AM GMT+02:00, Jean-Philippe Ouellet ***@***.***> wrote: Considering the case of someone with internal keyboard attached via USB, where sys-usb is not compromised and you only want to whitelist input-proxy to only the internal keyboard, then depending on what we choose to use as the device identifier argument an attacker wishing to get keyboard access to dom0 may be forced to correctly guess [some fields](http://wiki.osdev.org/Universal_Serial_Bus#DEVICE) (many of which are unique per device) which together amount to enough bits to be improbable unless it's a targeted attack you've posted verbose dmesgs online or such. Furthermore, if you leave the policy as "allow" for your internal one and "ask" for others, you would know something's wrong well before an attacker would be able to brute-force the correct ID. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #2783 (comment)

-- Rudd-O http://rudd-o.com/

[Rudd-O]

Excellent points. What I had in mind, essentially. This may need work on the policy plus argument bug , but that work was longstanding anyway.

…

On May 26, 2017 9:37:12 AM GMT+02:00, Jean-Philippe Ouellet ***@***.***> wrote: Considering the case of someone with internal keyboard attached via USB, where sys-usb is not compromised and you only want to whitelist input-proxy to only the internal keyboard, then depending on what we choose to use as the device identifier argument an attacker wishing to get keyboard access to dom0 may be forced to correctly guess [some fields](http://wiki.osdev.org/Universal_Serial_Bus#DEVICE) (many of which are unique per device) which together amount to enough bits to be improbable unless it's a targeted attack you've posted verbose dmesgs online or such. Furthermore, if you leave the policy as "allow" for your internal one and "ask" for others, you would know something's wrong well before an attacker would be able to brute-force the correct ID. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #2783 (comment)

-- Rudd-O http://rudd-o.com/

[marmarek]

This turned out to be slightly less straightforward, because input device do not need to be a USB device (so USB ID doesn't apply there). But there is "PRODUCT" property of input device, which have similar content - bus identifier + bus-specific identifier. In case of USB, it is vendor + product id.

[marmarek]

This turned out to be slightly less straightforward, because input device do not need to be a USB device (so USB ID doesn't apply there). But there is "PRODUCT" property of input device, which have similar content - bus identifier + bus-specific identifier. In case of USB, it is vendor + product id.