Input proxy doesn't handle hybrid keyboard+mouse devices

[marmarek]

In current settings, such devices would trigger two services: qubes.InputMouse and qubes.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

[marmarek]

Surely qubes.InputMouse shouldn't be attached to such device (because it's meant to mouse-only devices). The question is what should be? I see a few options:

• create another service qubes.InputKeyboardAndMouse, which would handle such devices
• extend existing qubes.InputKeyboard to also allow mouse events (perhaps then rename it to qubes.inputKeyboardAndMouse...

@rootkovska any opinion?

[marmarek]

Surely qubes.InputMouse shouldn't be attached to such device (because it's meant to mouse-only devices). The question is what should be? I see a few options:

• create another service qubes.InputKeyboardAndMouse, which would handle such devices
• extend existing qubes.InputKeyboard to also allow mouse events (perhaps then rename it to qubes.inputKeyboardAndMouse...

@rootkovska any opinion?

[marmarek]

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...
So preferably I'd either introduce new service for that and leave the old one too, or extend existing one, without renaming it.

[marmarek]

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...
So preferably I'd either introduce new service for that and leave the old one too, or extend existing one, without renaming it.

[rootkovska]

Yeah, we don't want to break existing services (especially they I use them on some of my machines already :P)

[rootkovska]

Yeah, we don't want to break existing services (especially they I use them on some of my machines already :P)

[marmarek]

I would go with extending existing service - qubes.InputKeyboard would allow both keyboard and mouse events. Any security drawbacks with that?

[marmarek]

I would go with extending existing service - qubes.InputKeyboard would allow both keyboard and mouse events. Any security drawbacks with that?

[rootkovska]

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.

[rootkovska]

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.

[rootkovska]

... 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]

... 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...

[marmarek]

@rootkovska do you have some wireless mouse? If so, could you check udevadm info -q all -n input/eventX (with appropriate event device) for ID_INPUT_* vars? To be sure that mouse is really visible as a mouse, not mouse+keyboard. Otherwise this change would break such setup...

[marmarek]

@rootkovska do you have some wireless mouse? If so, could you check udevadm info -q all -n input/eventX (with appropriate event device) for ID_INPUT_* vars? To be sure that mouse is really visible as a mouse, not mouse+keyboard. Otherwise this change would break such setup...

[marmarek]

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 qubes.InputKeyboard unconditionally would make it impossible to use mouse-only device (with keyboard access blocked)...
As this decision (whether to allow USB keyboard or not) needs to be made, I think it may simply affect all the input devices connected to the USB VM. Not sure about the details yet, maybe simply qubes.Input service with a configuration what kind of events should be allowed?

[marmarek]

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 qubes.InputKeyboard unconditionally would make it impossible to use mouse-only device (with keyboard access blocked)...
As this decision (whether to allow USB keyboard or not) needs to be made, I think it may simply affect all the input devices connected to the USB VM. Not sure about the details yet, maybe simply qubes.Input service with a configuration what kind of events should be allowed?

[ag4ve]

On Jan 16, 2016 7:37 PM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

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 qubes.InputKeyboard unconditionally would make
it impossible to use mouse-only device (with keyboard access blocked)...
As this decision (whether to allow USB keyboard or not) needs to be made,
I think it may simply affect all the input devices connected to the USB VM.
Not sure about the details yet, maybe simply qubes.Input service with a
configuration what kind of events should be allowed?

Maybe I'm misreading this but it might be best to just make the proxy's
kb/mouse device as a user decision. With or without this proxy VM, it's
probably the right thing to do to ask if a user wants to limit kb/mouse and
provide a pretty UI to do so. OTOH, I think trying to automate this either
leads to a system that's too open or too closed (as seems to be the case
with the Logitech test).

Ie, I have no use for you reducing security to support any wireless
kb/mouse (I don't have any and kinda disagree with their use). But maybe
I'd want the proxy to 'bring up' whatever interface my Ducky kb shows for
reprogramming (I don't really care about this but...). Further, IIRC I've
got 4x kb types and 3x mouse types here, so if I wanted support for any
hardware I'm likely to use here, I'd need to configure 7x devices. All
(except the Ducky) only provide one simple HID and that's what I'd expect
to allow.

[ag4ve]

On Jan 16, 2016 7:37 PM, "Marek Marczykowski-Górecki" <
notifications@github.com> wrote:

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 qubes.InputKeyboard unconditionally would make
it impossible to use mouse-only device (with keyboard access blocked)...
As this decision (whether to allow USB keyboard or not) needs to be made,
I think it may simply affect all the input devices connected to the USB VM.
Not sure about the details yet, maybe simply qubes.Input service with a
configuration what kind of events should be allowed?

Maybe I'm misreading this but it might be best to just make the proxy's
kb/mouse device as a user decision. With or without this proxy VM, it's
probably the right thing to do to ask if a user wants to limit kb/mouse and
provide a pretty UI to do so. OTOH, I think trying to automate this either
leads to a system that's too open or too closed (as seems to be the case
with the Logitech test).

Ie, I have no use for you reducing security to support any wireless
kb/mouse (I don't have any and kinda disagree with their use). But maybe
I'd want the proxy to 'bring up' whatever interface my Ducky kb shows for
reprogramming (I don't really care about this but...). Further, IIRC I've
got 4x kb types and 3x mouse types here, so if I wanted support for any
hardware I'm likely to use here, I'd need to configure 7x devices. All
(except the Ducky) only provide one simple HID and that's what I'd expect
to allow.

[marmarek]

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.

[marmarek]

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.

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc22 has been pushed to the r3.1 testing repository for the Fedora fc22 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc22 has been pushed to the r3.1 testing repository for the Fedora fc22 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc23 has been pushed to the r3.1 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc23 has been pushed to the r3.1 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc20 has been pushed to the r3.1 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-input-proxy-1.0.3-1.fc20 has been pushed to the r3.1 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-input-proxy-1.0.3-1.fc21 has been pushed to the r3.1 stable repository for the Fedora fc21 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc21 has been pushed to the r3.1 stable repository for the Fedora fc21 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc22 has been pushed to the r3.1 stable repository for the Fedora fc22 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc22 has been pushed to the r3.1 stable repository for the Fedora fc22 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc23 has been pushed to the r3.1 stable repository for the Fedora fc23 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc23 has been pushed to the r3.1 stable repository for the Fedora fc23 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-input-proxy-1.0.3-1.fc20 has been pushed to the r3.1 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-input-proxy-1.0.3-1.fc20 has been pushed to the r3.1 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