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]

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.

[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: 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?

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

[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/

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

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.

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

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

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

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.

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

[jpouellet]

QubesOS/qubes-desktop-linux-manager#29 adds code (R4-only) to notify the user when all their VMs get paused, with a button to unpause them all. This should avoid unpleasant surprises for new users trying to get Firefox incognito windows (or whatever else Ctrl+Shift+P happens to be). Once we have offline docs, another button could link to how to change the keyboard shortcut for it.

A next step would be to have some heuristic in gui-daemon automatically trigger single-VM pausing & a similar notification (because chances are the user probably won't have read the docs for this feature or remember it if/when they need it).

[jpouellet]

So, my initial attempt at solving this problem (QubesOS/qubes-desktop-linux-xfce4#4, QubesOS/qubes-core-admin-linux#14, QubesOS/qubes-desktop-linux-manager#29) was clearly not a desirable approach in retrospect, and ironically probably caused more accidental GUI self-DoSing (#4101, #4700) than actual mitigations of it.

It seems this is just not a common enough attack to warrant a solution that requires the user to be aware that such a mitigation ability exist, and also require intentional user (inter)action to make use of it. Some more nuanced heuristic-based approach in xside gui-daemon would be much more user-friendly, though may not even justify its own complexity.

Also, as @marmarek correctly points out in QubesOS/qubes-desktop-linux-xfce4#12, pausing all is not appropriate for the case where your input devices are not directly to dom0 (e.g. usb keyboard+mouse via sys-usb), because it creates a chicken-and-egg problem with having working input and unpausing the input-device(s) VM, so clearly the particular implementation was too heavy-handed.

I'm sorry to those I frustrated with the unfortunately-more-common-than-realized conflicting choice of keyboard shortcut.

[jpouellet]

That said... such GUI DoS situations do still arise, whether malicious or not, e.g. #4960

[v6ak]

There could be some less invasive mitigation, e.g. temporarily disabling always-on-top and freezing just the. GUI (maybe killall -STOP qubes-guid?). Then, it can also show a window explaining what has happened (maybe with few relevant buttons), so user who presses it accidentally does not get confused…