Override redirect protection does not consider multiple windows

[marmarek]

How to file a helpful issue

Qubes OS release

R4.0

Brief summary

Override-redirect protection protects against a single window covering the whole screen. Specifically, if a window with override-redirect flag covers more than 90% of the screen area, it's override-redirect flag is cleared. But, it does not consider multiple windows together covering the whole screen.

Steps to reproduce

1. Have multi-monitor system.
2. Install xfce4-screensaver in a VM.
3. Start it.

Expected behavior

Screen locking windows are converted to normal windows.

Actual behavior

Each monitor is covered with a separate, override-redirect window. Each use about 50% of the total screen area (depending on monitor resolutions), but together they cover it all.

In that case, one can still use qvm-xkill (bound to Ctrl+Alt+Esc by default), or switch to tty2 and kill the VM (or the process) from there.

Proposed solution

Consider not only a single window, but all the windows with override-redirect flag set. Sum their areas and compare that against screen area. For simplicity, do not consider their positions (this may lead to false-positives, when there are several small windows in the same place, but those should be rather unlikely).

I'm not sure what should be the action if they cross 90% threshold. Some ideas:

• unset the flag on the window causing the threshold to be crossed
• unset the flag on the biggest one (and continue until it's below the threshold)
• unset the flag on all of them

I'm leaning towards the last option, but requires checking what will happen in practice if a menu or a tooltip get the flag cleared (as a side effect).

[iamahuman]

Which measure do you think should be better for the purpose? The area of union of rectangles, or the covering bounding box?

[marmarek]

I'd say the former. The later could have frequent false-positives (like, four tiny windows in screen corners).

[iamahuman]

I just came up with some more scenarios override-redirect windows could be abused:

• The malicious VM opens up a bunch of small windows everywhere, covering up 90% - ε of the area. The only remaining controllable area becomes the tiny gaps between the windows.
• The malicious VM continuously changes the position of its windows, effectively obscuring from the user every area occupied in a small time window.
• The malicious VM spins up another Disposable VM, and they cooperate with each other to cover up the screen area.

Thus, in addition to union-of-rectangles, I suppose that the protection should:

1. Measure the state of window placement over a time window, rather than sampling it at a particular moment.
   • The simplest solution would be calculating the union over [t - k, t). This however may result in false positives (esp. if the user switches between menus frequently). Perhaps we can minimize the false positive with some fine-tuned convolution kernel over the time domain.
2. Detect whether there is at least one (or possibly more) continuous screen area (of some shape) not obscured by override-redirect windows.
3. Combine the two detection methods above.

[marmarek]

I don't want this check to be too complex, or too slow to compute... Maybe make the limit tighter (80%?) and/or add override-redirect windows number to the heuristic (10? 20?).
Note in R4.1 we have additional feature of enforcing (window manager defined) work area, which effectively means the panel cannot be obscured, regardless of number or size of the windows.

[DemiMarie]

I don't want this check to be too complex, or too slow to compute... Maybe make the limit tighter (80%?) and/or add override-redirect windows number to the heuristic (10? 20?).

Unless I am missing something (I probably am), 2 or 3 should be a reasonable limit.

[marmarek]

Unless I am missing something (I probably am), 2 or 3 should be a reasonable limit.

No, that will trivially cause false-positives. Take 2-level menu, add some notification and boom.

[DemiMarie]

Unless I am missing something (I probably am), 2 or 3 should be a reasonable limit.

No, that will trivially cause false-positives. Take 2-level menu, add some notification and boom.

Whoops! Then indeed I was missing something.

[github-actions]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)

[DemiMarie]

Still an issue in R4.1.

[DemiMarie]

Still affects 4.2, or at least I am not aware of a change that fixed it.