Implement protection from GUI "DoS" attacks

marmarek commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

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

jpouellet commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@rustybird Good point.

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

rustybird commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

\o/

jpouellet commented 7 years ago

I'll whip up a patch then. :)

jpouellet commented 7 years ago

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

jpouellet commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

v6ak commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

rustybird commented 7 years ago

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 commented 7 years ago

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

It avoids adding another thing to dom0
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 commented 7 years ago

@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 commented 7 years ago

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

jpouellet commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

On Wed, Nov 23, 2016 at 6:45 PM, Marek Marczykowski-Górecki notifications@github.com 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 commented 7 years ago

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

rustybird commented 7 years ago

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

v6ak commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@rustybird how does this look: https://github.com/QubesOS/qubes-core-admin-linux/pull/14

jpouellet commented 7 years ago

Closed by commit prematurely.

Still needs:

window killing mechanism
documentation

marmarek commented 7 years ago

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 commented 7 years ago

@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:

marmarek commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

v6ak commented 7 years ago

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:

Obviously, users have diffferent configuration experience.
Variant (a) requires handling the shortuts by some Qubes daemon rather than by DE. Variant (b) allows both.
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

User: Press Super
User: Press C
Qubes: InterVmCopy; Qubes notes that some keyboard shortcut has been pressed.
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.

User: Press Super
User: Press R
Qubes realizes that {Super, R} is not a subset of any Qubes-managed shortcut, so it will send all scancodes since now.
Qubes: Send keydown event of {Super, R} to the VM.
User releases R.
Qubes: Send keyup event of R
User releases Super.
Qubes: Send keyup event of Super
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.

User: Press Super
User: Release Super
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.
Qubes: Send keydown event of Super
Qubes: Send keyup event of Super

people with weird layouts

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

jpouellet commented 7 years ago

Remaining tasks:

[x] 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, & https://github.com/QubesOS/qubes-manager/pull/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 commented 7 years ago

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

CarpeNoctem commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Thanks! I see the commit now: https://github.com/marmarek/qubes-desktop-linux-xfce4/commit/9459331a3772decbaa3948cf6f45d98fd87ec800 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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

https://github.com/QubesOS/qubes-desktop-linux-manager/pull/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 commented 5 years ago

So, my initial attempt at solving this problem (https://github.com/QubesOS/qubes-desktop-linux-xfce4/pull/4, https://github.com/QubesOS/qubes-core-admin-linux/pull/14, https://github.com/QubesOS/qubes-desktop-linux-manager/pull/29) was clearly not a desirable approach in retrospect, and ironically probably caused more accidental GUI self-DoSing (https://github.com/QubesOS/qubes-issues/issues/4101, https://github.com/QubesOS/qubes-issues/issues/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 https://github.com/QubesOS/qubes-desktop-linux-xfce4/pull/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.

QubesOS / qubes-issues