Ideally, the system should take into account whether the application was installed from a repository or not. I think you can assume that an application installed from a trusted repository is safe. This would avoid a lot of spamming.

I would add that this problem is not limited to full screen mode, but to any kind of authorisation, such as microphone/webcam use, access to private data, etc.... so it might be relevant to find a common solution to all these issues. There was an excellent blog post about the way Gnome is intending to handle that : http://blogs.gnome.org/aday/2014/07/23/ ... me-part-2/

They intend to display a dialog at the first start of an application to give permissions. But this is part of a big push by Gnome to separate apps from the system, limiting the use of repositories for the system, distributing apps separately and running them in a sandbox. Therefore, it requires the implementation of a sandboxing system and a modification of the applications to handle the case where they are denied the permission. It may not be what Martin wants for the coming months, but I think the brainstorming shouldn't be limited to only full screen mode.

AGuiFr wrote:Ideally, the system should take into account whether the application was installed from a repository or not. I think you can assume that an application installed from a trusted repository is safe. This would avoid a lot of spamming.

This is the task of the distributor, that is the package provider to set it up correctly. It's also the reason why libWSM is created to provide a common infrastructure for all compositors.

AGuiFr wrote:I would add that this problem is not limited to full screen mode, but to any kind of authorisation, such as microphone/webcam use, access to private data, etc.... so it might be relevant to find a common solution to all these issues.

Let's please keep this thread focused. I deliberately wanted designer input and don't want to turn it into a security discussion. For the record: the use cases are similar but different. It's different as I want to make use of the capabilities a window manager/compositor has and don't need a generic deamon to interact with.

mgraesslin wrote:the technical side is relatively simple

Is it?

I'd be happy to hear so, but instead will bring my own (style plugin or library, set the environment to prefer my plugin "installation" path or preload my lib, run vlc (minimized), have my addition my my interpretation of a lockscreen interface.
Profit.

A trustworthy binary is usually statically linked and does not call dlopen(), what kinda drastically limits options here =)

Therefore i'd still propose to create a trustworthy binary (on all it's limitations) and flag that "good" to the user.
fabianr is imo on the right track here: the user would once provide a secret (image, icon or just a phrase) to the system and that secret is then stored w/o read access for users.
The pot. trusworthy process is then checked (hash signature) and in case, the "secret" is shown on screen.

mgraesslin wrote: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.

What exactly is the attack scenario here?
If we allow the "guy with the mouse" to permanentely whitelist an application, a bypassing attacker would just add his client after installing it.
An attacker who can get a process run w/o physical access will easily cheat the system if security checks apply on non-monolithic binaries.


I am really sorry for turning this (GUI request) into a more global discussion about security mechanisms, but have severe doubts that an approach of whitelisting a negative default could add any security here (thus only adds the UAC annoyance) at all.
Even if not annoying, it may just suggest false security - what's bad enough.

Security issues aside I have come up with a mockup that recycles a number of standard conventions. Not really sure if this is the kind of thing you're are after, but it serves as a starting point I suppose.

thanks Thomas, the style plugin is a good counter-example that it wouldn't work. I guess unless we have perfect sandboxing for all applications it cannot work - pity.

So yes, asking for a secret is probably the best solution. Only question is how to store it in a secure way with the locker as non-root being able to read it.

mgraesslin wrote:So yes, asking for a secret is probably the best solution. Only question is how to store it in a secure way with the locker as non-root being able to read it.

Could the locker not be changed to just ask for random digits of the password? Much like bank websites do? That way a malicious program will never be able to get the full password in one hit, and it will never know the correct length of it either. Or am I on the wrong end of the stick with this?

I take it my mockup is of no use now then

mgraesslin wrote:Only question is how to store it in a secure way with the locker as non-root being able to read it.

a) ACL
b) File permissions
c) encryption

(a) can probably not expected to be available and (c) gets us into the DRM junk (with the key/algorithm "stashed" in ksmserver - of course not "open source")

From your former post, I assumed this would not be much of an issue, since logind would open the (root:root, 600) file and hand it to "special" clients (ie. the session manager next to the compositor)?

davidwright wrote:Could the locker not be changed to just ask for random digits of the password?

No =)
It's handed to the PAM and that won't accept "almost parts of you password" for hash comparism
If you want to alter the access (and reg. a former idea of "2 factor access"), you could go for a different PAM, eg. http://linuxconfig.org/linux-authentica ... usb-device
If done right, this can be real funny (you plug in the USB key to login and when you unplug it, the screen is locked until you replug it)

luebking wrote:If you want to alter the access (and reg. a former idea of "2 factor access"), you could go for a different PAM, eg. http://linuxconfig.org/linux-authentica ... usb-device
If done right, this can be real funny (you plug in the USB key to login and when you unplug it, the screen is locked until you replug it)

That is quite interesting though. Imagine being able to do it using pairing with your phone. The kicker being that once you're out of wifi reception it would auto-lock the computer. Handy for people like me who keep going running to lunch and not locking their screens

It's usually done using bluetooth:
http://tjworld.net/wiki/Linux/Ubuntu/Bl ... AndLocking

Running out of wifi would be "problematic".
1. It will rapidly suck your mobiles battery to death
2. (good) WiFi spots can easily reach 20m (even in buildings) - let alone repeaters. If you lunch in-house or across the road, that may be not far enough.
Ok, there's a point to that:
"Boss, need more lunchtime to get my cellphone out of reach"™
... "Sure. You'll simply stay longer at night then." ;-P

mgraesslin wrote:

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.

I don't recommend doing this. First impressions are important, we don't want the first impression of wayland to be one which is really annoying with multiple prompts to take screenshots/full screen an app/move a window.

The Wayland security model is obviously an important step in sandboxing, but without all the other steps it doesn't have any practical value at the moment. There are many other ways to intercept the password here including our very own system to super easily change the look and feel package.

david_edmundson wrote:I don't recommend doing this. First impressions are important, we don't want the first impression of wayland to be one which is really annoying with multiple prompts to take screenshots/full screen an app/move a window.

Sorry I have to disagree here. It's much easier to implement the new world with security in the mind from the start, than to patch afterwards and having to issue CVEs. There will certainly not be a dialog asking for whether it's allowed to move a window and taking screenshots is not possible yet (yes that's not yet standardized at all). This thread here was only about the fullscreen windows, so let's not turn a mouse into an elephant.

david_edmundson wrote:The Wayland security model is obviously an important step in sandboxing, but without all the other steps it doesn't have any practical value at the moment. There are many other ways to intercept the password here including our very own system to super easily change the look and feel package.

Then we need to fix that! Improving the security of the screen locker architecture is on my TODO list for 5.2.

Well, one thing we could do is *not* use an overlay until a user begins keyboarding anything other than an escape sequence. This would allow many fullscreen applications to go without interruption (such as vlc) as these applications don't require keyboard input. This could also be a security setting in the system;

• Show security warnings on all untrusted full-screen applications
• Show security warnings when I begin typing into an untrusted full-screen application - default
• Do not show security warnings (DANGER WILL ROBINSON DANGER! KLAXXON!)

When the overlay is triggered, I would keep it simple; dim/blur the background, and superimpose;

• The users photo and account name (to help prove this is really the system)
• The name of the application and its icon
• That you should never type your password into this application
• [I Understand] [Get me outta here!]
• [X] Continue to show me this message (checked by default)

(or just dim if there's no compositing)

Kver wrote:This would allow many fullscreen applications to go without interruption (such as vlc) as these applications don't require keyboard input.

- Many remote controls appear to the system like keyboards
- Video keyboard navigation (to avoid the "invasive" panel)
- Tetris: "Press space to begin" -> "Game is lost"

About the mockup itself - thsi looks very much like what might be rather misleading.

or just dim if there's no compositing

Wayland always has "compositing" - on X11 this cannot be done (the client process can not be reliably detected against a malicious client, setting the wrong PID hint)
W/o compositing, you could btw. also forget about dimming

Intercepting the first keyboard events might be in deed annoying and might not help much. Consider a video player (e.g. VLC) which you want to pause by pressing space. There most likely is a really good reason to do so and users might not like being interrupted by something (phone rings). And then the space will nicely trigger either of the two buttons. So inexperienced user just continues to press space because it didn't pause and either the dialog just went away or $CURSE VLC ends fullscreen mode.

mgraesslin, out of interest: Suppose a window that is marked "Keep Above Others". Such windows can cover the panel, which should not be the case imho (the panel should *always* stay above all windows). Now suppose your window is marked above others and the malicious applications changes its minimum size to a value that does not fit the screen (neither horizontally, nor vertically). This is would now be kind of an Full screen window that could fake for example an log screen. Isn't that a security risk too?
Some needed corner cases like applications using CSDs (or the user hiding the window decoration) placed in a corner of the screen would certainly make this attack easy.

Apart from that: Currently in Plasma 5 there are some problems with dashboard: On top windows are always on top of Dashboard. This can only be solved by marking the Dashboard "on top" too, but then the panel would not be accessible. When the panel is always on top of any window (including dashboard) this would solve another problem.

Please forgive me being a little bit offtopic.

EDIT: Considering this from another perspective too: What can we do when the user has not plasma panel? The we would need to enforce window decorations for all windows (meaning CSD applications would be double decorated) and make sure the window decoration can't be moved outside the visible space, which sounds a lot more limiting.
Simply warning the user when he removes all panels is maybe a better idea, All of this would be useless however in the case Plasma crashes, because then applications could take over right?