New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input proxy doesn't handle hybrid keyboard+mouse devices #1618
Comments
Surely
@rootkovska any opinion? |
A note about renaming service - it would break existing setups when only dom0 or only template got updated. This may mean cutting someone from keyboard access... |
Yeah, we don't want to break existing services (especially they I use them on some of my machines already :P) |
I would go with extending existing service - |
Well qubes.InputKeyboard is already a serious security hole (and it's good it has "deny" policy by default), and I don't think adding mouse events to it might change much here. |
... of course qubes.InputKeyboard is still much better than having USB controller in Dom0, which has been the only way so far to support keyboard on some systems. There is a limit to what we can do in software... |
@rootkovska do you have some wireless mouse? If so, could you check |
I've checked that in the meantime - Logitech Unifying Receiver is discovered as keyboard+mouse device, even when it's paired only with a mouse. So directing this to |
This way possible fallback service wouldn't be triggered for already disconnected device QubesOS/qubes-issues#1618
This way possible fallback service wouldn't be triggered for already disconnected device QubesOS/qubes-issues#1618
This way possible fallback service wouldn't be triggered for already disconnected device QubesOS/qubes-issues#1618
On Jan 16, 2016 7:37 PM, "Marek Marczykowski-Górecki" <
Maybe I'm misreading this but it might be best to just make the proxy's Ie, I have no use for you reducing security to support any wireless |
The final solution is to try both in case of hybrid device. In short:
This way, it's up to the user to either allow or deny keyboard devices connected to USB VM. And in case of deny (the default), mouse events will be still allowed from hybrid devices. There is no GUI for setting qrexec policy yet, but that's just a single line in configuration. |
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
Or update dom0 via Qubes Manager. |
On fc23-based dom0 a single mouse+keyboard device is listed as two devices (one in "pointer" section, other as "keyboard"). This confuses 'xinput list', so add explicit request for device type. QubesOS/qubes-issues#1618
Hi, I am new with QubeOs, I didn't fully understand how to apply this solution. |
On Wed, Jun 03, 2020 at 09:37:41PM -0700, Alexander Finkelshtein wrote:
> The final solution is to try both in case of hybrid device. In short:
>
> * mouse only device - connect to `qubes.InputMouse`
> * keyboard only device - connect to `qubes.InputKeyboard`
> * keyboard+mouse device - connect to `qubes.InputKeyboard`, then if fails, connect to `qubes.InputMouse`
>
> `qubes.InputKeyboard` allows both keyboard and mouse events.
>
> This way, it's up to the user to either allow or deny keyboard devices connected to USB VM. And in case of deny (the default), mouse events will be still allowed from hybrid devices.
>
> There is no GUI for setting qrexec policy yet, but that's just a single line in configuration.
Hi, I am new with QubeOs, I didn't fully understand how to apply this solution.
what would be the single line to make it work?
Configuration is done by editing a file in dom0:
the files referred to `qubes.InputMouse` etc, are to be found in
/etc/qubes-rpc/policy
The suggestion is that you should edit appropriate file for you case.
Look at the "Manual Setup" section at
https://www.qubes-os.org/doc/usb-qubes
|
In current settings, such devices would trigger two services:
qubes.InputMouse
andqubes.InputKeyboard
, attached to the same device. Only the first one will succeed, the other one would not receive any events. Apparently in most cases mouse wins.More info:
https://groups.google.com/d/msgid/qubes-users/56928E93.6030305%40noses.com
The text was updated successfully, but these errors were encountered: