Forbid qube windows from overlaying trusted menus

[DemiMarie]

The problem you're addressing (if any)

Currently, it is possible for a qube window with the override redirect property flag set to prevent the user from interacting with critical, trusted UI elements. QubesOS/qubes-gui-daemon#71 will protect the taskbar from this, but that is not enough to allow the user to readily stop such a qube without using command-line tools or magic keybindings.

Describe the solution you'd like

We should ensure that trusted menus cannot be covered by untrusted windows.

Where is the value to a user, and who might that user be?

All users will benefit from improved reliability

Describe any alternative solutions you've considered

None

Additional context

This subsumes the existing protection against overlaying the screensaver

---

Relevant documentation you've consulted

None

Related, non-duplicate issues

4960

[DemiMarie]

Current plan is to forbid app qube windows from overlaying GUI qube windows that are of state _NET_WM_STATE_ABOVE or that are focused and of type _NET_WM_STATE_FULLSCREEN, as per the Extended Window Manager Hits specification.

[unman]

On Mon, Jul 12, 2021 at 11:19:02PM -0700, Demi Marie Obenour wrote:

Current plan is to forbid app qube windows from overlaying GUI qube windows that are of state _NET_WM_STATE_ABOVE or that are focused and of type _NET_WM_STATE_FULLSCREEN, as per the Extended Window Manager Hits specification.

If users want to display a window or application full screen, currently the window will fill the screen regardless of the panel setting (in KDE at any rate). That is what they want and expect. If I understand your reply, the "current plan" will change that behaviour, and they will have to first change state on the panel to achieve the same display. Is that right?

[DemiMarie]

On Mon, Jul 12, 2021 at 11:19:02PM -0700, Demi Marie Obenour wrote: Current plan is to forbid app qube windows from overlaying GUI qube windows that are of state _NET_WM_STATE_ABOVE or that are focused and of type _NET_WM_STATE_FULLSCREEN, as per the Extended Window Manager Hits specification. If users want to display a window or application full screen, currently the window will fill the screen regardless of the panel setting (in KDE at any rate). That is what they want and expect. If I understand your reply, the "current plan" will change that behaviour, and they will have to first change state on the panel to achieve the same display. Is that right?

It will cover everything except for the taskbar at the top of the screen, its border, and any _NET_WM_STATE_ABOVE or focused _NET_WM_STATE_FULLSCREEN windows in the GUI qube. Under normal circumstances, there will be no such windows, so only the taskbar will be on top. This is important as it allows the user to regain control of the system without resorting to “magic” keybindings.

[marmarek]

If users want to display a window or application full screen, currently the window will fill the screen regardless of the panel setting (in KDE at any rate). That is what they want and expect. If I understand your reply, the "current plan" will change that behaviour, and they will have to first change state on the panel to achieve the same display. Is that right?

You can set a VM's window "above" or "fullscreen", using window manager's controls (right click on the title bar menu, or equivalent key combo). It's just VM cannot do it on its own by default. There is a GUI daemon option (disabled by default) to allow a VM to set "fullscreen" state. https://www.qubes-os.org/doc/how-to-enter-fullscreen-mode/ (for R4.0, on R4.1 it is achieved via qvm-features: https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html#gui-gui-default).

[marmarek]

Generally, I think it is a good idea, we do similar thing already to avoid popping above a screen locker.

[andrewdavidwong]

We'll have some users who don't yet understand the implications of full screen windows, and certainly some users will want to watch full-screen movies, etc. I'm guessing we want some kind of interactivity to educate these users and elicit their desired outcome:

1. Window attempts to go full screen.
2. Something pops up in dom0: "The window in the qube just tried to go full screen. Full screen windows can attempt to impersonate dom0 or prevent you from controlling your system. Do you want to let this window go full screen? [Yes] [No] [(x)] Never ask me again]"

I'm sure all of this could be done better, but you get the idea.

[DemiMarie]

@ninavizz suggested a persistent overlay of some sort, so that users always know that a window has gone fullscreen and can always regain control. I will leave the details to her.

[ninavizz]

@DemiMarie I feel like a jerk asking this, but... I don't exactly understand what the original comment is describing. Or what a "trusted menu" is. Mind describing for me what a user would see—bothas things are today, and as this issue proposes? And, what the intent is between both?

[DemiMarie]

@DemiMarie I feel like a jerk asking this, but... I don't exactly understand what the original comment is describing. Or what a "trusted menu" is. Mind describing for me what a user would see—bothas things are today, and as this issue proposes? And, what the intent is between both?

You aren’t a jerk :smile:.

A trusted menu would be the app menu, or the menu one gets when clicking on one’s username. Right now, I believe that qubes can overlay such menus with an override redirect window, but I am not certain of this. The window would obviously have its normal border. The purpose of this change would be to prevent that from happening.

That said, I think a solution for full-screen is much more urgent and important. Full-screen is a very real use-case with significant security consequences.