Last week I had been at the X.org Developer Conference and there was an interesting talk about security. One of the discussed problems are fullscreen applications.

A malicious fullscreen window could fake to be the screen locker and thus trick the user into entering his password into the window of the fake window. On X11 there's not much we can do about it, but on Wayland we can.

The idea would be to ask the user whether it's OK for the window to go fullscreen (compare what browsers do). Only very trusted windows it would not ask for. E.g. for our own screen locker we would obviously not ask, but for a fake screen locker we would ask. Thus the user cannot be tricked into entering the password into a fake dialog.

I would like the VDG to come up with a good design for an overlay KWin could show on top of a fullscreen window (on Wayland). The overlay should contain enough information for an uninformed user to understand what's going on with the ability to get full information about the process in question for the advanced users. Also please think about whether one should see the window already or whether it's completely blocked, etc. etc.

If you have any questions, please ask.

To clarify. Are you asking for something to be shown before the window goes full screen? e.g When you click the full screen button in VLC a box or something would show up asking you to confirm that this is OK? Or are you looking for something to show when the application is already in fullscreen mode? e.g When you move your mouse something would show up at the top or something so you know it's an application?

I would leave that up to the VDG to decide. Firefox and Chrome are showing the dialog after the window went fullscreen. So this might be a point for doing the same. It's also more connected and might be better in case a window opens fullscreen directly.

As in the thread about password dialogs: Depending on the time-frame, we may be able to provide detailed scientific input on this as well.

colomar wrote:As in the thread about password dialogs: Depending on the time-frame, we may be able to provide detailed scientific input on this as well.

for this one I would prefer having a solution in three months. I want to have the fullscreen secure as soon as we start to support fullscreen windows in KWin/Wayland which will be either Plasma 5.2 or 5.3.

mgraesslin wrote:for this one I would prefer having a solution in three months. I want to have the fullscreen secure as soon as we start to support fullscreen windows in KWin/Wayland which will be either Plasma 5.2 or 5.3.

Okay, so that probably will exclude evaluation through student projects, but we can still provide literature input. Thank you for the info!

Do you really intend to have some sort of UAC dialog everytime i turn mplayer fullscreen, start a game, ...?

What would be those "very trusted windows" and how would they be determined (hash on the binary?)
If I can add random clients to that list, what would ensure not some malicious plugin in such client caused the dialog? Can the user actully take an informed decision about which application is trustworthy?
What about a preloaded library as atack vector?

There's a very good reason for browsers to catch this, because you're in the wild. Some random xss attack might cause some random javascript to try to trick the user and there's hardly ever a reason for a script to turn a browser fullscreen and you can easily define urls which may or may not do so, but on a local system?
I frankly see an annoyance factor which might ultimately just make users ignore that "nasty warning, click" when it actually matters.

luebking wrote:Do you really intend to have some sort of UAC dialog everytime i turn mplayer fullscreen, start a game, ...?

...

I frankly see an annoyance factor which might ultimately just make users ignore that "nasty warning, click" when it actually matters.

Those are my fears as well. A bit like the situation windows has with the big screen blocking confirmation notices.

I can understand it flagging up once, but I think there should be a way of adding an application to a trusted list so it will never show up again.

My counter proposal would be to flag the screenlocker, ie. instead of "this is not the screenlocker, but it may feign to be" a "this *is* the screenlocker and you can safely enter your password"

The problem is about how to do that in a way that can not be faked (this is also the problem with the password dialog flagging - where I frankly doubt a plasmoid that could be faked by few lines of QML could be the solution. Leaving aside that other dialogs like gksu - or whatever that is called - may be just as legit)

And:
the problem to solve before this is "how do we guarantee this client is not captured in any way" which more or less means the binary and *every* loaded library (what about dlopen?) must be signed in some way, evtl. even requires to hash the process memory....

Maybe you could show a common secret (between the user and the "system") in the screen locker or the password dialog. Eg a picture or an avatar. Since this authenticates the system to the user, displaying it on the screen shouldn't matter. Of cause screen recording should not be possible while this happens.

luebking wrote:My counter proposal would be to flag the screenlocker, ie. instead of "this is not the screenlocker, but it may feign to be" a "this *is* the screenlocker and you can safely enter your password"

Just riffing on this. How about some kind of two way authorisation on the screen locker? Maybe the screen locker could present a QR code that could be scanned with your phone and confirmed with KDE Connect? Something along those lines.

I guess, like in a web browser, it would allow to set up an application to be a 'safe' one. So, for mplayer, it would be shown the first time and you'd be able to click 'always allow'.

the problem is, that when i (or kwin or any process running on my user) can edit this list, a malicious process running with my user privs (what can be assumed here) can do as well.
therefore such list must be ro and you'd trigger a priv escalation to manipulate it...

the technical side is relatively simple: there is ongoing work for a libWSM (Wayland Security Module, see same talk at XDC) which would allow a compositor to ask whether a client is allowed to go fullscreen. So all we need to do is add a checkbox to "allow always" in the same UI and it would never ask again. Also libWSM is designed in a way that applications, compositors and distributions can ship pre-defined rules. This would allow to e.g. VLC just ship a rule to always go fullscreen. If the distributor would package correctly it would just work(tm).

luebking wrote:the problem is, that when i (or kwin or any process running on my user) can edit this list, a malicious process running with my user privs (what can be assumed here) can do as well.

exactly, users might not be allowed to override it. It needs to be root-owned. It also means that scripts and rules may not override the selection. Modifying for KWin (or any other compositor) will not be a problem, though. We can ask logind (as we are the session controller) to open us the required resource.