Implement protection from GUI "DoS" attacks

[marmarek]

Reported by omeg on 5 Jul 2014 11:00 UTC
VMs can make life in dom0 hard by displaying override-redirect windows or just making a lot of them. This can be prevented by implementing a method to temporarily hide all VM windows and disable any GUI output. This may be a configurable hotkey (guid.conf).

Migrated-From: https://wiki.qubes-os.org/ticket/881

---

Note to any contributors who wish to work on this issue: Please either ask for details or propose a design before starting serious work on this.

[marmarek]

Comment by joanna on 26 Sep 2014 20:00 UTC
For now you can press Alt-F2 (in KDE) and get a "command prompt" this way.

[marmarek]

Comment by joanna on 26 Sep 2014 20:00 UTC
For now you can press Alt-F2 (in KDE) and get a "command prompt" this way.

[marmarek]

Poor man solution: press Ctrl-Alt-Esc and select a window to kill. This will terminate related GUI daemon, so all the window of given VM will be gone. Then launching anything in that VM will restart related GUI daemon, and bring back all the windows. In the meantime you may decide to kill the VM, access its console etc.

[marmarek]

Poor man solution: press Ctrl-Alt-Esc and select a window to kill. This will terminate related GUI daemon, so all the window of given VM will be gone. Then launching anything in that VM will restart related GUI daemon, and bring back all the windows. In the meantime you may decide to kill the VM, access its console etc.

[rustybird]

Doesn't work with override_redirect windows though, apparently xkill ignores them.

[rustybird]

Doesn't work with override_redirect windows though, apparently xkill ignores them.

[jpouellet]

One possible solution would be additional trusted keyboard shortcuts.

A trusted shortcut (like control-shift-C) to pause the frontmost vm would at least prevent it from making any new windows. You are not able to close windows of a paused VM, but if you had another trusted keyboard shortcut to bring qubes-manager to the front (as I do), then you could kill the offending VM.

[jpouellet]

One possible solution would be additional trusted keyboard shortcuts.

A trusted shortcut (like control-shift-C) to pause the frontmost vm would at least prevent it from making any new windows. You are not able to close windows of a paused VM, but if you had another trusted keyboard shortcut to bring qubes-manager to the front (as I do), then you could kill the offending VM.

[rustybird]

@jpouellet: That's a clever idea! Maybe even have this keyboard shortcut pause all VMs, using qvm-run --pause --all? Otherwise, the DOSing VM could detect that Ctrl-Shift is being pressed (before the key combination is complete), close the window, and reopen it shortly afterwards.

[rustybird]

@jpouellet: That's a clever idea! Maybe even have this keyboard shortcut pause all VMs, using qvm-run --pause --all? Otherwise, the DOSing VM could detect that Ctrl-Shift is being pressed (before the key combination is complete), close the window, and reopen it shortly afterwards.

[rustybird]

@jpouellet: And if all VMs are paused, the responsible GUI daemon can be killed race free by replacing Xfwm's current xkill keyboard shortcut with this (which works with both regular and override_redirect windows):

#!/bin/sh
set -e

ID=$(xdotool selectwindow)
xprop -id "$ID" _QUBES_VMNAME | grep -q ' = '  # safety check: don't kill dom0 windows
xdotool windowkill "$ID"

[rustybird]

@jpouellet: And if all VMs are paused, the responsible GUI daemon can be killed race free by replacing Xfwm's current xkill keyboard shortcut with this (which works with both regular and override_redirect windows):

#!/bin/sh
set -e

ID=$(xdotool selectwindow)
xprop -id "$ID" _QUBES_VMNAME | grep -q ' = '  # safety check: don't kill dom0 windows
xdotool windowkill "$ID"

[jpouellet]

@rustybird Good point.

Is this something we want upstream? If so, which keys do you think make sense?

[jpouellet]

@rustybird Good point.

Is this something we want upstream? If so, which keys do you think make sense?

[rustybird]

@jpouellet:

Is this something we want upstream?

@marmarek, do you like this approach (and shipping xdotool in dom0)?

If so, which keys do you think make sense?

Ctrl-Shift-P for pause would be nice, but unfortunately github.com of all things uses this combo to switch between Preview and Write when writing comments. :|

The kill script above could bind to Ctrl-Alt-Esc, replacing xkill.

[rustybird]

@jpouellet:

Is this something we want upstream?

@marmarek, do you like this approach (and shipping xdotool in dom0)?

If so, which keys do you think make sense?

Ctrl-Shift-P for pause would be nice, but unfortunately github.com of all things uses this combo to switch between Preview and Write when writing comments. :|

The kill script above could bind to Ctrl-Alt-Esc, replacing xkill.

[marmarek]

@marmarek, do you like this approach (and shipping xdotool in dom0)?

Yes, look fine!

As for key combo - maybe something even harder to press accidentally - Alt-Ctrl-Shift-P ?

Is it possible to cancel the killing script without actually killing anything - again - if pressed accidentally? I haven't found any way. Don't worry, just curious - I think xkill is also impossible to cancel (other than killing the process manually).

[marmarek]

@marmarek, do you like this approach (and shipping xdotool in dom0)?

Yes, look fine!

As for key combo - maybe something even harder to press accidentally - Alt-Ctrl-Shift-P ?

Is it possible to cancel the killing script without actually killing anything - again - if pressed accidentally? I haven't found any way. Don't worry, just curious - I think xkill is also impossible to cancel (other than killing the process manually).

[jpouellet]

Is it possible to cancel the killing script without actually killing anything - again - if pressed accidentally?

Yes, just click on any dom0 window, as it is then a noop.

[jpouellet]

Is it possible to cancel the killing script without actually killing anything - again - if pressed accidentally?

Yes, just click on any dom0 window, as it is then a noop.

[marmarek]

\o/

[marmarek]

\o/

[jpouellet]

I'll whip up a patch then. :)

[jpouellet]

I'll whip up a patch then. :)

[jpouellet]

@marmarek What is the preferred way to submit pull requests that span multiple repos?

[jpouellet]

@marmarek What is the preferred way to submit pull requests that span multiple repos?

[jpouellet]

@marmarek The easiest place to put these is in the xfwm shortcuts settings, but then it working depends on the desktop environment. Would gui-daemon/gui-daemon/xside.c like the ctrl-shift-c/v clipboard stuff be more appropriate?

[jpouellet]

@marmarek The easiest place to put these is in the xfwm shortcuts settings, but then it working depends on the desktop environment. Would gui-daemon/gui-daemon/xside.c like the ctrl-shift-c/v clipboard stuff be more appropriate?

[marmarek]

Having it in gui-daemon would work only when VM window is active - so VM could avoid this by hiding the window as @rustybird explained. So, better do it as xfce shortcut. Then KDE, i3, awesome, ...

As for the script itself, it may be in gui-daemon, or core-admin-linux.

[marmarek]

Having it in gui-daemon would work only when VM window is active - so VM could avoid this by hiding the window as @rustybird explained. So, better do it as xfce shortcut. Then KDE, i3, awesome, ...

As for the script itself, it may be in gui-daemon, or core-admin-linux.

[marmarek]

Maybe there is some generic standard for registering global keyboard shortcuts in desktop environments?

[marmarek]

Maybe there is some generic standard for registering global keyboard shortcuts in desktop environments?

[v6ak]

I know I am going beyond scope of this post, but it is related: Global shortcuts (other than well-known like Alt+F4) should IMHO contain Meta key, because this key is usually not present in application-specific shortcuts:

• The pause-all-VMs should do so. I am currently not aware of any collision with the current proposal, but I believe someone will find one.
• The supercopy/superpaste also should do so. I had come collision (probably with IntelliJ IDEA), so I've remmaped them to Meta+C and Meta+V.
• I am not suggesting to change default desktop environment mapping to something else. I am just suggesting that Qubes should not add more potential collisions.

[v6ak]

I know I am going beyond scope of this post, but it is related: Global shortcuts (other than well-known like Alt+F4) should IMHO contain Meta key, because this key is usually not present in application-specific shortcuts:

• The pause-all-VMs should do so. I am currently not aware of any collision with the current proposal, but I believe someone will find one.
• The supercopy/superpaste also should do so. I had come collision (probably with IntelliJ IDEA), so I've remmaped them to Meta+C and Meta+V.
• I am not suggesting to change default desktop environment mapping to something else. I am just suggesting that Qubes should not add more potential collisions.

[rustybird]

@v6ak: Do you mean the Super key(s)? I don't seem to have any Meta or Hyper keys on my Thinkpad, but the "Side view of four qubes waving around, suggesting inter-qube data flow" key maps to Super_L according to xev.

Also, do all keyboards relevant for Qubes have such keys?

[rustybird]

@v6ak: Do you mean the Super key(s)? I don't seem to have any Meta or Hyper keys on my Thinkpad, but the "Side view of four qubes waving around, suggesting inter-qube data flow" key maps to Super_L according to xev.

Also, do all keyboards relevant for Qubes have such keys?

[v6ak]

@rustybird You are right, I mean Super key. While there are various keyboard modifications, I don't remember any recent keyboard without Super key. (I don't count specialized keyboards like numpad-only.)

[v6ak]

@rustybird You are right, I mean Super key. While there are various keyboard modifications, I don't remember any recent keyboard without Super key. (I don't count specialized keyboards like numpad-only.)

[andrewdavidwong]

I use an IBM Model M manufactured in 1990. It doesn't have a Super key.

But as long as I can reassign the shortcut in /etc/qubes/guid.conf (or elsewhere), I'll be fine. 😄

[andrewdavidwong]

I use an IBM Model M manufactured in 1990. It doesn't have a Super key.

But as long as I can reassign the shortcut in /etc/qubes/guid.conf (or elsewhere), I'll be fine. 😄

[rustybird]

Maybe there is some generic standard for registering global keyboard shortcuts in desktop environments?

I'd really love to know that too. Launching xbindkeys might be another option.

For Xfce only (must be run as the regular user, not root):

shortcut() {
    for sub in default custom; do
        xfconf-query --channel xfce4-keyboard-shortcuts \
                     --property "/commands/$sub/$1" \
                     --type string --create --set "$2"
    done
}

shortcut '<Control><Shift><Alt>p' 'qvm-run --pause --all'
shortcut '<Control><Alt>Escape'   'qvm-xkill'

<Super>p could be used instead of <Control><Shift><Alt>p above, if overriding the shortcut for the Display settings (also available via System Tools) is okay.

[rustybird]

Maybe there is some generic standard for registering global keyboard shortcuts in desktop environments?

I'd really love to know that too. Launching xbindkeys might be another option.

For Xfce only (must be run as the regular user, not root):

shortcut() {
    for sub in default custom; do
        xfconf-query --channel xfce4-keyboard-shortcuts \
                     --property "/commands/$sub/$1" \
                     --type string --create --set "$2"
    done
}

shortcut '<Control><Shift><Alt>p' 'qvm-run --pause --all'
shortcut '<Control><Alt>Escape'   'qvm-xkill'

<Super>p could be used instead of <Control><Shift><Alt>p above, if overriding the shortcut for the Display settings (also available via System Tools) is okay.

[jpouellet]

@rustybird I'd prefer to use whatever already-provided shortcut mechanism we have rather than adding another (like xbindkeys), for two reasons:

1. It avoids adding another thing to dom0
2. It allows users to re-configure their keyboard shortcuts in the native way they would expect to for their respective window managers. Using the xfce graphical keyboard shortcut editor, or opening your i3 config in $EDITOR and searching for the shortcut you wish to change is a natural thing. Having to first figure out where the shortcuts are actually coming from violates the principle of least surprise.

[jpouellet]

@rustybird I'd prefer to use whatever already-provided shortcut mechanism we have rather than adding another (like xbindkeys), for two reasons:

1. It avoids adding another thing to dom0
2. It allows users to re-configure their keyboard shortcuts in the native way they would expect to for their respective window managers. Using the xfce graphical keyboard shortcut editor, or opening your i3 config in $EDITOR and searching for the shortcut you wish to change is a natural thing. Having to first figure out where the shortcuts are actually coming from violates the principle of least surprise.

[rustybird]

@jpouellet:

I'd prefer to use whatever already-provided shortcut mechanism we have rather than adding another (like xbindkeys), for two reasons: [...]

Agreed. Also, xbindkeys has too many dependencies (guile and tcl, tk)

[rustybird]

@jpouellet:

I'd prefer to use whatever already-provided shortcut mechanism we have rather than adding another (like xbindkeys), for two reasons: [...]

Agreed. Also, xbindkeys has too many dependencies (guile and tcl, tk)

[v6ak]

I have nothing against configurability of keyboard shortcuts. I just wanted to discuss some reasonable default.

[v6ak]

I have nothing against configurability of keyboard shortcuts. I just wanted to discuss some reasonable default.

[jpouellet]

So, can we reach consensus on a good keyboard shortcut to use? That's the only thing I'm blocking on for implementing this.

Proposed solutions are:

• Ctrl+Shift+P
• Ctrl+Alt+Shift+P
• Meta+P (and if so, potentially shift Ctrl+Shift+{C,V} to Meta+{C,V} for consistency?)

We could also overload Ctrl+Alt+Esc (kill window) to pause everything first as well. This may be undesired and counter-intuitive to potential users though, idk.

---

I personally like the idea of reserving an entire modifier (e.g. Meta) for "trusted shortcuts". This could be used as a non-conflicting subset of the keyboard modifier namespace reserved for Qubes, trusted window-management (e.g. to prove a password prompt is truly a window of a trusted VM and not just being drawn inside a less-trusted window), etc.

We could prevent all keypress events with this modifier from reaching the guest, such that it becomes much harder for a guest to guess when a trusted keyboard shortcut is about to be delivered for various GUI-related attacks (as you can currently do by sniffing Ctrl+Shift).

I have been considering making a separate proposal to this effect, but wanted to come up with a PoC first.

[jpouellet]

So, can we reach consensus on a good keyboard shortcut to use? That's the only thing I'm blocking on for implementing this.

Proposed solutions are:

• Ctrl+Shift+P
• Ctrl+Alt+Shift+P
• Meta+P (and if so, potentially shift Ctrl+Shift+{C,V} to Meta+{C,V} for consistency?)

We could also overload Ctrl+Alt+Esc (kill window) to pause everything first as well. This may be undesired and counter-intuitive to potential users though, idk.

---

I personally like the idea of reserving an entire modifier (e.g. Meta) for "trusted shortcuts". This could be used as a non-conflicting subset of the keyboard modifier namespace reserved for Qubes, trusted window-management (e.g. to prove a password prompt is truly a window of a trusted VM and not just being drawn inside a less-trusted window), etc.

We could prevent all keypress events with this modifier from reaching the guest, such that it becomes much harder for a guest to guess when a trusted keyboard shortcut is about to be delivered for various GUI-related attacks (as you can currently do by sniffing Ctrl+Shift).

I have been considering making a separate proposal to this effect, but wanted to come up with a PoC first.

[marmarek]

I like Ctrl+Shift+P - for consistency and harder to press accidentally (unlike Meta+P). On the other hand, my cat is able to press Alt+Ctrl+F2 - I have no idea how ;)

As for entire modifier for trusted operations - IMO it should be something more than just one key - otherwise surely we'll have some conflict. For example Meta+Tab is one of few methods for switching focus inside Windows VM (in non-seamless mode). Maybe Meta+Alt or such. But then, it will not have this nice effect of being totally invisible to VMs...

[marmarek]

I like Ctrl+Shift+P - for consistency and harder to press accidentally (unlike Meta+P). On the other hand, my cat is able to press Alt+Ctrl+F2 - I have no idea how ;)

As for entire modifier for trusted operations - IMO it should be something more than just one key - otherwise surely we'll have some conflict. For example Meta+Tab is one of few methods for switching focus inside Windows VM (in non-seamless mode). Maybe Meta+Alt or such. But then, it will not have this nice effect of being totally invisible to VMs...

[jpouellet]

On Wed, Nov 23, 2016 at 6:45 PM, Marek Marczykowski-Górecki ***@***.***> wrote: I like Ctrl+Shift+P - for consistency and harder to press accidentally (unlike Meta+P). On the other hand, my cat is able to press Alt+Ctrl+F2 - I have no idea how ;)

Haha, nice :) Reminds me of the child accidentally finding the gnome-screensaver bypass :)

As for entire modifier for trusted operations - IMO it should be something more than just one key - otherwise surely we'll have some conflict. For example Meta+Tab is one of few methods for switching focus inside Windows VM

AFAIK virtually all keyboards (even Model Ms) have at least 4 suitable modifiers, likely more, so I think a dedicated qubes modifier not-conflicting with anything else is a very reasonable proposition. Not counting Fn, I have 6 physical buttons at the bottom of my keyboard to choose from. In reality all my applications only need ctrl (1) or alt (2). It is so incredibly rare to find a program which cares whether left or right ctrl/alt is pressed that I think we can safely reassign the lesser-used side. I can easily assign one of the easily reachable keys to be a qubes modifier (3), and still have a comfortable compose key (4) and maybe want a lesser-priority "windows key" (5) for HVM in non-seamless mode.

Maybe Meta+Alt or such. But then, it will not have this nice effect of being totally invisible to VMs...

Right, another argument in favor of a single modifier.

[jpouellet]

On Wed, Nov 23, 2016 at 6:45 PM, Marek Marczykowski-Górecki ***@***.***> wrote: I like Ctrl+Shift+P - for consistency and harder to press accidentally (unlike Meta+P). On the other hand, my cat is able to press Alt+Ctrl+F2 - I have no idea how ;)

Haha, nice :) Reminds me of the child accidentally finding the gnome-screensaver bypass :)

As for entire modifier for trusted operations - IMO it should be something more than just one key - otherwise surely we'll have some conflict. For example Meta+Tab is one of few methods for switching focus inside Windows VM

AFAIK virtually all keyboards (even Model Ms) have at least 4 suitable modifiers, likely more, so I think a dedicated qubes modifier not-conflicting with anything else is a very reasonable proposition. Not counting Fn, I have 6 physical buttons at the bottom of my keyboard to choose from. In reality all my applications only need ctrl (1) or alt (2). It is so incredibly rare to find a program which cares whether left or right ctrl/alt is pressed that I think we can safely reassign the lesser-used side. I can easily assign one of the easily reachable keys to be a qubes modifier (3), and still have a comfortable compose key (4) and maybe want a lesser-priority "windows key" (5) for HVM in non-seamless mode.

Maybe Meta+Alt or such. But then, it will not have this nice effect of being totally invisible to VMs...

Right, another argument in favor of a single modifier.

[jpouellet]

@rustybird can you elaborate on what problem your xkill alternative solves?

[jpouellet]

@rustybird can you elaborate on what problem your xkill alternative solves?

[rustybird]

@jpouellet xkill doesn't allow selecting VM windows without a title bar, but xdotool windowselect/windowkill does.

[rustybird]

@jpouellet xkill doesn't allow selecting VM windows without a title bar, but xdotool windowselect/windowkill does.

[v6ak]

I like Ctrl+Shift+P - for consistency

Yes, it is more consistent with current defaults for clipboard.

harder to press accidentally (unlike Meta+P)

OK, unlike copy&paste, this one is expected to be used rather rarely and the hard-to-reach approach looks good. But still, I would like the shortcut to include Meta, in order to be less likely to collide with an existing keyboard shortcut.

For example Meta+Tab is one of few methods for switching focus inside Windows VM (in non-seamless mode).

Maybe I am opposing something else, but: I did not suggest that we should remap all well-known shortcuts like Alt+Tab or Alt+F4. Since they are well-known, they are unlikely to collide with app's shortcuts. OTOH, for new shortcuts (unknown for large part of world) should IMHO include it.

OT: I usually use Meta+Alt+Tab, this works well on both Ubuntu (the WM used in Unity) and Windows.

Maybe Meta+Alt or such. But then, it will not have this nice effect of being totally invisible to VMs...

Hmm, invisibility to VMs looks interesting, but I am not sure if I want this. For example, on both Windows (either on HVM or over RDP) and Ubuntu, I frequently use Meta to open system menu. But maybe, the press of Meta could be delayed and passed iff no Qubes global key shortcut is used. This would make all reasonable behavior (Win+Tab, Meta for system menu, …) I can think of still working, while it would hide the keypresses when using functions like PauseAll, InterVmCopy and InterVmPaste.

In reality all my applications only need ctrl (1) or alt (2).

Try IntelliJ IDEA, you'll get nice shortcuts like Ctrl+Alt+Shift+C…

It is so incredibly rare to find a program which cares whether left or right ctrl/alt is pressed that I think we can safely reassign the lesser-used side.

Counter-examples:

• Some keyboard layouts map right alt to something special (called “Alt Gr”). I remember that standard Czech keyboard does so (needed for keys like “\”, “&”, “@” or “€”) and I believe there are some other relatively common layouts (maybe Polish layout or various Cyrillic layouts) doing the same.
• For Ctrl, Remmina is a notable exception. (Also VirtualBox, but who would run Virtualbox under Qubes…?) I cannot imagine using Remmina on Qubes if one of Ctrl keys was used by Qubes.

This idea has one more issue: What is the lesser-used side? Touch-typists will probably press Ctrl with the other hand (e.g., CtrlR+C, CtrlR+Q, CtrlL+L, CtrlL+K on traditional keyboards with QWERTY layout). Before touch-typing, I used to use the same hand (e.g., CtrlL+C, CtrlL+Q, CtrlR+L, CtrlR+K). Having to use only one of the Ctrls would be painful with traditional keyboard layout. (Well, I could handle it on Ergodox keyboard, because all the modifiers are well reachable by thumbs and I can modify the layout, but still…)

[v6ak]

I like Ctrl+Shift+P - for consistency

Yes, it is more consistent with current defaults for clipboard.

harder to press accidentally (unlike Meta+P)

OK, unlike copy&paste, this one is expected to be used rather rarely and the hard-to-reach approach looks good. But still, I would like the shortcut to include Meta, in order to be less likely to collide with an existing keyboard shortcut.

For example Meta+Tab is one of few methods for switching focus inside Windows VM (in non-seamless mode).

Maybe I am opposing something else, but: I did not suggest that we should remap all well-known shortcuts like Alt+Tab or Alt+F4. Since they are well-known, they are unlikely to collide with app's shortcuts. OTOH, for new shortcuts (unknown for large part of world) should IMHO include it.

OT: I usually use Meta+Alt+Tab, this works well on both Ubuntu (the WM used in Unity) and Windows.

Maybe Meta+Alt or such. But then, it will not have this nice effect of being totally invisible to VMs...

Hmm, invisibility to VMs looks interesting, but I am not sure if I want this. For example, on both Windows (either on HVM or over RDP) and Ubuntu, I frequently use Meta to open system menu. But maybe, the press of Meta could be delayed and passed iff no Qubes global key shortcut is used. This would make all reasonable behavior (Win+Tab, Meta for system menu, …) I can think of still working, while it would hide the keypresses when using functions like PauseAll, InterVmCopy and InterVmPaste.

In reality all my applications only need ctrl (1) or alt (2).

Try IntelliJ IDEA, you'll get nice shortcuts like Ctrl+Alt+Shift+C…

It is so incredibly rare to find a program which cares whether left or right ctrl/alt is pressed that I think we can safely reassign the lesser-used side.

Counter-examples:

• Some keyboard layouts map right alt to something special (called “Alt Gr”). I remember that standard Czech keyboard does so (needed for keys like “\”, “&”, “@” or “€”) and I believe there are some other relatively common layouts (maybe Polish layout or various Cyrillic layouts) doing the same.
• For Ctrl, Remmina is a notable exception. (Also VirtualBox, but who would run Virtualbox under Qubes…?) I cannot imagine using Remmina on Qubes if one of Ctrl keys was used by Qubes.

This idea has one more issue: What is the lesser-used side? Touch-typists will probably press Ctrl with the other hand (e.g., CtrlR+C, CtrlR+Q, CtrlL+L, CtrlL+K on traditional keyboards with QWERTY layout). Before touch-typing, I used to use the same hand (e.g., CtrlL+C, CtrlL+Q, CtrlR+L, CtrlR+K). Having to use only one of the Ctrls would be painful with traditional keyboard layout. (Well, I could handle it on Ergodox keyboard, because all the modifiers are well reachable by thumbs and I can modify the layout, but still…)

[jpouellet]

@v6ak Okay, so clearly this needs more thought and feedback. Thank you for your feedback :)

Some specific responses in this case:

• Some keyboard layouts map right alt to something special (called “Alt Gr”). I remember that standard Czech keyboard does so (needed for keys like “\”, “&”, “@” or “€”) and I believe there are some other relatively common layouts (maybe Polish layout or various Cyrillic layouts) doing the same.

It is relatively common for french keyboards to have such a key too. In linux, this is often mapped to the compose key which was my #4 above.

• For Ctrl, Remmina is a notable exception. (Also VirtualBox, but who would run Virtualbox under Qubes…?) I cannot imagine using Remmina on Qubes if one of Ctrl keys was used by Qubes.

IMO If a suggested change gives a significant benefit to all Qubes users (and I admit this remains to be proven in this case) at the cost of a small subset of people needing to remap a key, I think this is a fine outcome. https://xkcd.com/1172/

This idea has one more issue: What is the lesser-used side? Touch-typists will probably press Ctrl with the other hand

Indeed, this is an oversight on my part. I touch-type and use only my left ctrl/alt. I falsely assumed this was true for others.

It still sounds reasonable to me to think that we could assign a single key as a qubes-modifier. Which key, however, remains an open question.

[jpouellet]

@v6ak Okay, so clearly this needs more thought and feedback. Thank you for your feedback :)

Some specific responses in this case:

• Some keyboard layouts map right alt to something special (called “Alt Gr”). I remember that standard Czech keyboard does so (needed for keys like “\”, “&”, “@” or “€”) and I believe there are some other relatively common layouts (maybe Polish layout or various Cyrillic layouts) doing the same.

It is relatively common for french keyboards to have such a key too. In linux, this is often mapped to the compose key which was my #4 above.

• For Ctrl, Remmina is a notable exception. (Also VirtualBox, but who would run Virtualbox under Qubes…?) I cannot imagine using Remmina on Qubes if one of Ctrl keys was used by Qubes.

IMO If a suggested change gives a significant benefit to all Qubes users (and I admit this remains to be proven in this case) at the cost of a small subset of people needing to remap a key, I think this is a fine outcome. https://xkcd.com/1172/

This idea has one more issue: What is the lesser-used side? Touch-typists will probably press Ctrl with the other hand

Indeed, this is an oversight on my part. I touch-type and use only my left ctrl/alt. I falsely assumed this was true for others.

It still sounds reasonable to me to think that we could assign a single key as a qubes-modifier. Which key, however, remains an open question.

[jpouellet]

@rustybird how does this look: QubesOS/qubes-core-admin-linux#14

[jpouellet]

@rustybird how does this look: QubesOS/qubes-core-admin-linux#14

[jpouellet]

Closed by commit prematurely.

Still needs:

• window killing mechanism
• documentation

[jpouellet]

Closed by commit prematurely.

Still needs:

• window killing mechanism
• documentation

[marmarek]

It will get closed few more times ;) Anyway I prefer this way, because we'll get here notification when packages got uploaded to some repository.

[marmarek]

It will get closed few more times ;) Anyway I prefer this way, because we'll get here notification when packages got uploaded to some repository.

[jpouellet]

@marmarek So does that mean I should continue to use "fixes ..." in the case of relevant commits even when they do not completely fix an issue?

I used "addresses ..." instead in:

• QubesOS/qubes-desktop-linux-xfce4#5
• QubesOS/qubes-desktop-linux-xfce4#6

[jpouellet]

@marmarek So does that mean I should continue to use "fixes ..." in the case of relevant commits even when they do not completely fix an issue?

I used "addresses ..." instead in:

• QubesOS/qubes-desktop-linux-xfce4#5
• QubesOS/qubes-desktop-linux-xfce4#6

[marmarek]

For builder-github notification, I'd say use "fixes ..." in the last commit related to the issue, in given repository - this will result in notification at appropriate time (all relevant changes released). So, if "partially fixes" means "more work to do in this repository, not done yet" - use something else (personally I add bare issue reference, without any prefix), but if it means "the other part is in another repository" - add "fixes" prefix.
Yes, I know, this is abuse of this syntax. But IMO it's still better than inventing our own.

[marmarek]

For builder-github notification, I'd say use "fixes ..." in the last commit related to the issue, in given repository - this will result in notification at appropriate time (all relevant changes released). So, if "partially fixes" means "more work to do in this repository, not done yet" - use something else (personally I add bare issue reference, without any prefix), but if it means "the other part is in another repository" - add "fixes" prefix.
Yes, I know, this is abuse of this syntax. But IMO it's still better than inventing our own.

[v6ak]

It still sounds reasonable to me to think that we could assign a single key as a qubes-modifier. Which key, however, remains an open question.

I think this is the point we agree. I just believe that the key could be Meta Super, while you prefer RCtrl.

[v6ak]

It still sounds reasonable to me to think that we could assign a single key as a qubes-modifier. Which key, however, remains an open question.

I think this is the point we agree. I just believe that the key could be Meta Super, while you prefer RCtrl.

[jpouellet]

I just believe that the key could be Meta, while you prefer RCtrl.

Not sure where you get that idea. I am currently using left alt. From watching xev output it appears that I do not have a Meta key. I believe you mean Super key again. I think Super makes a lot of sense, given how other OSes also use it for their own OS shortcuts (speaking especially of Windows here), and accordingly it seems comparatively sparingly used by user applications.

Regardless, it doesn't matter much to me what key is actually chosen, but rather just that some key be chosen. It can then be configurable to allow for people with weird layouts (or strong preferences, or wanting to reserve it for an inner Windows VM or such) to adjust accordingly, as @andrewdavidwong stated he wanted.

It appears to me that we are blocking only on identifying a non-controversial default. I vote for @rustybird's suggestion of the "Side view of four qubes waving around, suggesting inter-qube data flow" key :) At least on my keyboard this key maps as Super.

[jpouellet]

I just believe that the key could be Meta, while you prefer RCtrl.

Not sure where you get that idea. I am currently using left alt. From watching xev output it appears that I do not have a Meta key. I believe you mean Super key again. I think Super makes a lot of sense, given how other OSes also use it for their own OS shortcuts (speaking especially of Windows here), and accordingly it seems comparatively sparingly used by user applications.

Regardless, it doesn't matter much to me what key is actually chosen, but rather just that some key be chosen. It can then be configurable to allow for people with weird layouts (or strong preferences, or wanting to reserve it for an inner Windows VM or such) to adjust accordingly, as @andrewdavidwong stated he wanted.

It appears to me that we are blocking only on identifying a non-controversial default. I vote for @rustybird's suggestion of the "Side view of four qubes waving around, suggesting inter-qube data flow" key :) At least on my keyboard this key maps as Super.

[andrewdavidwong]

I vote for @rustybird's suggestion of the "Side view of four qubes waving around, suggesting inter-qube data flow" key :) At least on my keyboard this key maps as Super.

It's astonishing that keyboard manufacturers were able to foresee the rise of Qubes so many years ago. 😄

[andrewdavidwong]

I vote for @rustybird's suggestion of the "Side view of four qubes waving around, suggesting inter-qube data flow" key :) At least on my keyboard this key maps as Super.

It's astonishing that keyboard manufacturers were able to foresee the rise of Qubes so many years ago. 😄

[v6ak]

Not sure where you get that idea. I am currently using left alt.

Neither am I. Maybe I got the idea of RCtrl after reading your idea of using left/right ctrl/alt and after thinking of usage of RCtrl in Remmina/VirtualBox.

It can then be configurable to allow for people with weird layouts

It looks like we mostly agree there. However, the configurability can be either (a) user configures the Qubes key and all shortcuts are configured automatically then (so, shortcuts would look like QubesKey+C, QubesKey+V, and QubesKey would be defined elsewhere), or (b) user configures all shortcuts separately. This has both technical and functional consequences:

1. Obviously, users have diffferent configuration experience.
2. Variant (a) requires handling the shortuts by some Qubes daemon rather than by DE. Variant (b) allows both.
3. Both variants allow not sending the QubesKey scancode to the VM until it is clear user does not want to press any Qubes shortcut, but this requires handling all the Qubes-related shortcuts by Qubes.

Few examples for not sending QubesKey scancode too early:

Maybe it is not clear why we should want this, so I'll describe some examples. It would hide scancodes of the Qubes shortcuts. However, it would allow usage of shortcuts like Super+R or just Super, even when QubesKey = Super.

If it is not clear how it should behave generally, I could write some pseudocode that handles all those shortcuts this way. (Maybe I could write few variants with different handling of some edge cases.)

Let QubesKey = Super, CopyShortcut = QubesKey + C. Consider few scenarios. I write all of them as sequences. When multiple events are written in one list item, I don't care about their order. No scancodes are sent to VM unless I explicitly write so.

Copying

1. User: Press Super
2. User: Press C
3. Qubes: InterVmCopy; Qubes notes that some keyboard shortcut has been pressed.
4. User: Release both Super and C (in any order)

Using Win+R shortcut in a HVM (useful with Windows)

I've intentionally written this scenario with releasing R before releasing the Win, because it is more complex.

1. User: Press Super
2. User: Press R
3. Qubes realizes that {Super, R} is not a subset of any Qubes-managed shortcut, so it will send all scancodes since now.
4. Qubes: Send keydown event of {Super, R} to the VM.
5. User releases R.
6. Qubes: Send keyup event of R
7. User releases Super.
8. Qubes: Send keyup event of Super
9. Qubes now realizes that no keys are pressed, so it disables sending all the shortcuts and switches back to filtering keys.

Using Win (i.e., Super) to open Start Menu / Dash in a Windows / Ubuntu HVM

Note: Similar scenarios would be tricky to support fully for long common prefixes of Qubes-managed shortcuts. But I believe this is rather edge case.

1. User: Press Super
2. User: Release Super
3. Qubes realizes that all keys are released and key filtering is still on. This implies that the keys have been filtered, but no Qubes-managed shortcut was used.
4. Qubes: Send keydown event of Super
5. Qubes: Send keyup event of Super

people with weird layouts

Like me? :) https://twitter.com/v6ak/status/720648320528551936

[v6ak]

Not sure where you get that idea. I am currently using left alt.

Neither am I. Maybe I got the idea of RCtrl after reading your idea of using left/right ctrl/alt and after thinking of usage of RCtrl in Remmina/VirtualBox.

It can then be configurable to allow for people with weird layouts

It looks like we mostly agree there. However, the configurability can be either (a) user configures the Qubes key and all shortcuts are configured automatically then (so, shortcuts would look like QubesKey+C, QubesKey+V, and QubesKey would be defined elsewhere), or (b) user configures all shortcuts separately. This has both technical and functional consequences:

1. Obviously, users have diffferent configuration experience.
2. Variant (a) requires handling the shortuts by some Qubes daemon rather than by DE. Variant (b) allows both.
3. Both variants allow not sending the QubesKey scancode to the VM until it is clear user does not want to press any Qubes shortcut, but this requires handling all the Qubes-related shortcuts by Qubes.

Few examples for not sending QubesKey scancode too early:

Maybe it is not clear why we should want this, so I'll describe some examples. It would hide scancodes of the Qubes shortcuts. However, it would allow usage of shortcuts like Super+R or just Super, even when QubesKey = Super.

If it is not clear how it should behave generally, I could write some pseudocode that handles all those shortcuts this way. (Maybe I could write few variants with different handling of some edge cases.)

Let QubesKey = Super, CopyShortcut = QubesKey + C. Consider few scenarios. I write all of them as sequences. When multiple events are written in one list item, I don't care about their order. No scancodes are sent to VM unless I explicitly write so.

Copying

1. User: Press Super
2. User: Press C
3. Qubes: InterVmCopy; Qubes notes that some keyboard shortcut has been pressed.
4. User: Release both Super and C (in any order)

Using Win+R shortcut in a HVM (useful with Windows)

I've intentionally written this scenario with releasing R before releasing the Win, because it is more complex.

1. User: Press Super
2. User: Press R
3. Qubes realizes that {Super, R} is not a subset of any Qubes-managed shortcut, so it will send all scancodes since now.
4. Qubes: Send keydown event of {Super, R} to the VM.
5. User releases R.
6. Qubes: Send keyup event of R
7. User releases Super.
8. Qubes: Send keyup event of Super
9. Qubes now realizes that no keys are pressed, so it disables sending all the shortcuts and switches back to filtering keys.

Using Win (i.e., Super) to open Start Menu / Dash in a Windows / Ubuntu HVM

Note: Similar scenarios would be tricky to support fully for long common prefixes of Qubes-managed shortcuts. But I believe this is rather edge case.

1. User: Press Super
2. User: Release Super
3. Qubes realizes that all keys are released and key filtering is still on. This implies that the keys have been filtered, but no Qubes-managed shortcut was used.
4. Qubes: Send keydown event of Super
5. Qubes: Send keyup event of Super

people with weird layouts

Like me? :) https://twitter.com/v6ak/status/720648320528551936

[jpouellet]

Remaining tasks:

• write man page for qvm-xkill (done)
• sync man page to docs on site
• assign default shortcut for pause all & qvm-xkill
  • choosing shortcuts appears to be controversial (see comments in this thread, & QubesOS/qubes-manager#19)
  • all shortcut-assignment bikesheds could be resolved with a qubes-specific modifier, but that is also controversial (https://groups.google.com/d/topic/qubes-devel/poVtf6X0-BM/discussion)
• document shortcuts in anti-DoS page on site

[jpouellet]

Remaining tasks:

• write man page for qvm-xkill (done)
• sync man page to docs on site
• assign default shortcut for pause all & qvm-xkill
  • choosing shortcuts appears to be controversial (see comments in this thread, & QubesOS/qubes-manager#19)
  • all shortcut-assignment bikesheds could be resolved with a qubes-specific modifier, but that is also controversial (https://groups.google.com/d/topic/qubes-devel/poVtf6X0-BM/discussion)
• document shortcuts in anti-DoS page on site

[jpouellet]

Fixes: ... OK for tracking, but this should not be closed yet. See above.

[jpouellet]

Fixes: ... OK for tracking, but this should not be closed yet. See above.

[CarpeNoctem]

Did this get implemented recently, or in Qubes 4.x in general as Ctrl+Shift+P?
As you know, Firefox is the default browser in Qubes.
Ctrl+Shift+P is the hotkey in Firefox to open a new Private Browsing window. I use this quite frequently, for sanity checking and viewing URLs as a non-logged-in user, etc.

This used to work on my Qubes 3.x machines. I'm not sure if it has ever worked on my new 4.x (GA, not beta) install, but a few times recently when I've tried opening a new Private Browsing window in Firefox, my whole machine appears to get into what appears to be a corrupted state.
Took me a while to figure out that what was happening was all of my VMs getting paused. :(

[CarpeNoctem]

Did this get implemented recently, or in Qubes 4.x in general as Ctrl+Shift+P?
As you know, Firefox is the default browser in Qubes.
Ctrl+Shift+P is the hotkey in Firefox to open a new Private Browsing window. I use this quite frequently, for sanity checking and viewing URLs as a non-logged-in user, etc.

This used to work on my Qubes 3.x machines. I'm not sure if it has ever worked on my new 4.x (GA, not beta) install, but a few times recently when I've tried opening a new Private Browsing window in Firefox, my whole machine appears to get into what appears to be a corrupted state.
Took me a while to figure out that what was happening was all of my VMs getting paused. :(

[marmarek]

Ough, that's indeed what is happening. So, we need a better shortcut. I wonder whether Ctrl+Win+P would be ok (and generally using Win key in default key combos)? I haven't seen any keyboard without this key for a looong time, but it might be region specific. Any opinions? @andrewdavidwong @rustybird @jpouellet @v6ak
I think we shouldn't use just Win/Super as default QubesKey (@v6ak comment above), because it's very useful for standard window manager actions (and AFAIR default window-manager key in i3). But maybe combined with Ctrl would be ok? Or Alt+Win/Super?

BTW There is also Ctrl+Shift+Alt+P to unpause all.

[marmarek]

Ough, that's indeed what is happening. So, we need a better shortcut. I wonder whether Ctrl+Win+P would be ok (and generally using Win key in default key combos)? I haven't seen any keyboard without this key for a looong time, but it might be region specific. Any opinions? @andrewdavidwong @rustybird @jpouellet @v6ak
I think we shouldn't use just Win/Super as default QubesKey (@v6ak comment above), because it's very useful for standard window manager actions (and AFAIR default window-manager key in i3). But maybe combined with Ctrl would be ok? Or Alt+Win/Super?

BTW There is also Ctrl+Shift+Alt+P to unpause all.

[CarpeNoctem]

Thanks! I see the commit now: marmarek/qubes-desktop-linux-xfce4@9459331
However, testing just now, Ctrl+Alt+Shift+P didn't unpause for me, and I got an error message from qvm-run --unpause --all
[EDIT: The reason unpause hotkey doesn't work for me is because Alt+Shift changes between keyboard layouts for me and is caught before the unpause sequence. The reason the qvm-run command didn't work for me is because the implementation seems to have been migrated to qvm-unpause --all. ]

[CarpeNoctem]

Thanks! I see the commit now: marmarek/qubes-desktop-linux-xfce4@9459331
However, testing just now, Ctrl+Alt+Shift+P didn't unpause for me, and I got an error message from qvm-run --unpause --all
[EDIT: The reason unpause hotkey doesn't work for me is because Alt+Shift changes between keyboard layouts for me and is caught before the unpause sequence. The reason the qvm-run command didn't work for me is because the implementation seems to have been migrated to qvm-unpause --all. ]

[CarpeNoctem]

I should note, for anyone running into this - You can remove or change the hotkey for qvm-pause --all in the XFCE Keyboard settings dialog (Main menu -> System Tools -> Keyboard -> Application Shortcuts).

[CarpeNoctem]

I should note, for anyone running into this - You can remove or change the hotkey for qvm-pause --all in the XFCE Keyboard settings dialog (Main menu -> System Tools -> Keyboard -> Application Shortcuts).

[jpouellet]

Yep. Conflicting keyboard shortcuts are definitely a problem, and not just for pausing.

My suggestion a year ago was to pick a qubes-specific modifier sequence used for all qubes keyboard shortcuts and let the user override it.

In practice this means having something listening for keyboard presses not configured by xfce4-keyboard-settings, which I'm not sure I like - too much "magic" and different entities with separate configuration that the user needs to be aware of. I think the idea at the time was that there was going to be some central gui for all qubes settings (incl. guid.conf, etc.) so that this behavior would be obvious to the user, but that has not happened.

Not sure what's best at this point.

[jpouellet]

Yep. Conflicting keyboard shortcuts are definitely a problem, and not just for pausing.

My suggestion a year ago was to pick a qubes-specific modifier sequence used for all qubes keyboard shortcuts and let the user override it.

In practice this means having something listening for keyboard presses not configured by xfce4-keyboard-settings, which I'm not sure I like - too much "magic" and different entities with separate configuration that the user needs to be aware of. I think the idea at the time was that there was going to be some central gui for all qubes settings (incl. guid.conf, etc.) so that this behavior would be obvious to the user, but that has not happened.

Not sure what's best at this point.

[v6ak]

As far as I know, barring letters/symbols/numbers, regional keyboard variants don't differ so much. Some (Czech/Slovak/Polish/…) have AltGr instead of RightAlt. Japanese keyboards tend to have extra keys and smaller spacebar [1], but they tend to have Windows key [2]. Czech/Slovak keyboards probably tend to have numpad more often [3], but it does not matter there. I might have missed something, but other layouts don't seem to be much special, even Chinese layout seems to be rather conservative. On MacBooks, the command key reportedly acts as super key. [4] I have looked for MS requirements for Windows key, but I haven't found any mention they require its presence. On potential collision with WM shortcuts: You are right in theory – it might happen. But I don't thing this is very likely. And even if it happens, we can handle it case-by-case for the WM where it happens. Given the number of supported WMs, this is probably not going to be a real painpoint, compared to collisions with countless apps it might accidentally collide with. I prefer making the distinction rather simple – shortcuts with Super might be caught by dom0, others ideally shouldn't [5]. Using Super+Ctrl for every Qubes-related shortcut managed by dom0 seems to be overkill. I am OK for using Super+Ctrl+P (or even Super+LAlt+RCtrl+LShift+P :P) for such rarely-used shortcuts, but not in general – inter-VM copy&paste should be as simple as Super+C and Super+V. We should not blend our fingers on common tasks. The @CarpeNoctem's trouble to figure out how to unpause it all has inspired me to some UX idea: there should be some pop-up explaining what has happened and allowing to unpause it all. [1] http://xahlee.info/kbd/Japan_keyboard_layouts.html [2] https://www.google.com/search?q=japan+keyboard&client=firefox-b&prmd=ivns&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiTiIfwj_7aAhVCjywKHQ36D2MQ_AUIBigB [3] Czech/Slovak usually prefer diacritics over digraphs, so diacritics characters are very common. For easier typing, some frequent letters with diacritics are in number row. For writing numbers on number row, one has to use Shift key when using Czech/Slovak layout. [4] https://help.ubuntu.com/community/AppleKeyboard [5] I am OK with keeping well-known shortcuts like Alt+Tab and even some DE-speciffic shortcuts, as remapping them to something else could do more harm. I just think QubesOS should not introduce new dom0-related shortcuts without Super key.

[v6ak]

As far as I know, barring letters/symbols/numbers, regional keyboard variants don't differ so much. Some (Czech/Slovak/Polish/…) have AltGr instead of RightAlt. Japanese keyboards tend to have extra keys and smaller spacebar [1], but they tend to have Windows key [2]. Czech/Slovak keyboards probably tend to have numpad more often [3], but it does not matter there. I might have missed something, but other layouts don't seem to be much special, even Chinese layout seems to be rather conservative. On MacBooks, the command key reportedly acts as super key. [4] I have looked for MS requirements for Windows key, but I haven't found any mention they require its presence. On potential collision with WM shortcuts: You are right in theory – it might happen. But I don't thing this is very likely. And even if it happens, we can handle it case-by-case for the WM where it happens. Given the number of supported WMs, this is probably not going to be a real painpoint, compared to collisions with countless apps it might accidentally collide with. I prefer making the distinction rather simple – shortcuts with Super might be caught by dom0, others ideally shouldn't [5]. Using Super+Ctrl for every Qubes-related shortcut managed by dom0 seems to be overkill. I am OK for using Super+Ctrl+P (or even Super+LAlt+RCtrl+LShift+P :P) for such rarely-used shortcuts, but not in general – inter-VM copy&paste should be as simple as Super+C and Super+V. We should not blend our fingers on common tasks. The @CarpeNoctem's trouble to figure out how to unpause it all has inspired me to some UX idea: there should be some pop-up explaining what has happened and allowing to unpause it all. [1] http://xahlee.info/kbd/Japan_keyboard_layouts.html [2] https://www.google.com/search?q=japan+keyboard&client=firefox-b&prmd=ivns&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiTiIfwj_7aAhVCjywKHQ36D2MQ_AUIBigB [3] Czech/Slovak usually prefer diacritics over digraphs, so diacritics characters are very common. For easier typing, some frequent letters with diacritics are in number row. For writing numbers on number row, one has to use Shift key when using Czech/Slovak layout. [4] https://help.ubuntu.com/community/AppleKeyboard [5] I am OK with keeping well-known shortcuts like Alt+Tab and even some DE-speciffic shortcuts, as remapping them to something else could do more harm. I just think QubesOS should not introduce new dom0-related shortcuts without Super key.