I’m sorry for the lack of information, but I thought I’d better make a record of this.
I’m not worried about any security issues on my own machine. This post is purely about making this known, so that if it’s actually a bug, it starts the process to getting it fixed.
As far as I’m aware, this should not be able to happen…
BACKGROUND:
Full-screen is disabled on all of my machines
STEPS TO RECREATE:
I had Firefox open in a Qube (this forum, actually…)
I was holding my laptop with my thumb around the space bar, V, C, X, D, F, etc. keys
I can’t remember exactly what keys I pressed (my thumb jiggled, and I think I might have pressed the Alt key and/or the Super key)
I looked up at the screen, and Firefox was full-screen and obscuring the XFCE panel
I pressed F11 twice, and Firefox then went full-screen without obscuring the XFCE panel, as per the expected behaviour
PARTICULARS:
Qubes 4.1
qubes-dom0-current-testing branch
fedora-34 template
If anyone needs any more information, I’ll gladly provide it, but I don’t really know what else I can provide that would be helpful…
In the docs you’ll see that this is possible.
Because the Window Manager is trusted in dom0 (or equivalent), any WM
functions will be considered safe.
In Xfce and KDE it’s straightforward to use WM processes to go full
screen, even overlaying the panel.
Provided there are trusted WM options to get out of Full Screen this
shouldn’t be a problem.
To clarify: disabling fullscreen means that the domU vm can’t force fullscreen (e.g. if an attacker has a foothold in a domU). But you, as the dom0 user, can.
Just to clarify, I am not concerned about the security of my own (testing) machine, nor am I after any sort of reassurance that “everything is fine on my machine”.
I do appreciate it nonetheless, though
——
I understand that when full-screen is disabled Qubes Global Settings, when the user makes an AppVM full-screen, the XFCE panel and cursor are not covered. At least, that has consistently been my experience with Qubes OS since day 1 all those years ago.
VLC, YouTube videos, mpv, Steam games, etc. have all behaved consistently when I have instructed them to go “full-screen”, in that the dom0 XFCE panel, the AppVM title bar and the cursor would always be visible and unobscured.
This was different. All three of these things were hidden.
——
The reason why I brought this up (under the “testing” tag, as opposed to “user support”) was to address:
Whether it should or shouldn’t be possible to do to so, based on the Qubes OS codebase
Whether the devs knew about it
Whether there is an expectation from an end user that this should not be possible, particularly when there is an option in end user setting to “disable full-screen”, and the end user has set it
Whether there is potential for exploitation of this, such as the justification of Qubes OS disabling full-screen by default, just in case an AppVM actually pretends to be the Qubes OS desktop
It looks like they do, so this post fulfilled its purpose
There are (at least) two different ways that you, as the human operating the computer, can try to make an app qube window go fullscreen:
You click on some button, say the “fullscreen” button in the corner of a YouTube video that’s playing. This is on a web page, in a browser, in an app qube. (It could be anything in the app qube; this is just an example.)
You command the window manager in dom0 (e.g., through a keyboard shortcut or right-click menu option on the title bar) to make a window fullscreen.
The first method shouldn’t allow content from inside the app qube to cover the entire physical screen, but the second option should. Why? Because, in the second case, you, as the trusted human operating the computer, are commanding the window manager in dom0, which is ultimately trusted, to do something. Since there is no untrusted directive coming from anywhere (like from inside of an app qube), there is no reason not to do it, and there is nothing unsafe or insecure about it. There is nothing inherently unsafe or insecure about you telling Qubes OS to make content from this app qube cover the entire screen, as long as you know you’re doing it (and therefore hopefully won’t be tricked by it).
(However, in this case, you said you didn’t intentionally trigger it and don’t know how you did it, so that actually is a bit concerning, but it’s more of a UX problem than a security problem, IMHO.)
This would never obscure the XFCE panel or the window title bar, no matter what I tried.
This did obscure the XFCE panel and the window title bar, and that is what caught me off-guard.
Totally agree. But if there’s an expectation from the end user that leaving full-screen disabled in Qubes Global Settings would basically not allow this to happen, it could potentially lead even tech-savvy people to raise a few eyebrows…
“Hmmm…I just managed to make an AppVM full-screen, even though it’s disabled…wait…if I can do it, that means a background process could do it too…oh no…” And potentially panic…
I know I pressed a key combination, but I’m at a loss as to what potential key combination of keys around the ones I pressed at the time would make Firefox go full-screen.
Alt +F, or Super + F, maybe?
Even if it was a key combination, that would mean that the full-screen operation was done by the dom0 window manager, as opposed to the AppVM. That would make sense, but I can still see it causing uneasiness among some users (even the veteran Linux and BSD Chads), especially if they are fairly new to Qubes…
It may have caught you off guard, but this is all the correct and intended behavior.
It sounds like the problem lies in the mistaken expectation. How can we avoid giving users (or allowing them to form) this mistaken expectation? Maybe the problem is the name of the setting. “Disable fullscreen” might not be specific enough.
Yeah, this is the other big UX problem. It probably shouldn’t be too easy to accidentally trigger something potentially dangerous without an easy way to back out of it. For example, maybe hitting that keyboard shortcut should result in a prompt that explains what’s going on and asks you to confirm that you want to proceed (with some options like “turn this feature off” and “don’t ask for confirmation anymore”).
Please feel free to open an issue for this, if there isn’t one already.
