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

Right now we do a pretty bad job concerning password dialogs. There is no way for the user to know that the dialog is really a system dialog and it's easy for a malicious application to fake an authentication dialog and trick the user into entering the root password (think of e.g. the polkit dialogs).

The challenge for us is to design a dialog which makes it obvious for the user that it's really the system asking for the password and that any other dialog should not be trusted. During the talk there were several ideas discussed which technically only the system could do (e.g. wobble the window) but those seem to me like not obvious for normal users. This makes it a little bit difficult to design a good dialog.

My personal suggestion would be to provide a password service in plasma. E.g. whenever polkit needs to ask for a password, it doesn't open a dialog, but it's plasma serving the password request by e.g. opening the notification area.

But that's just one idea, there might be better ones. So please VDG think about this topic. I'm especially interested in colomar's opinion on the topic.

Hi Martin, first of all thanks for sharing what you have been up to!

Isn't that where window decorations come in? When we do not rely on CSD the applications can't change the window decoration. So couldn't those password dialogs use a window decoration theme that is especially reserved for that purpose? The problem I see with that though is applications that implement CSD, that could maybe fake the look of the window decoration, so this does not seem like the best idea right?
A plasma input dialog seems like a really good option imho, though what implications does this have on the portability of applications? Will there be a unified protocol for all applications, no matter if they come from the gnome camp or the KDE camp? What about those applications on other platforms?

kdeuserk wrote:Isn't that where window decorations come in? When we do not rely on CSD the applications can't change the window decoration. So couldn't those password dialogs use a window decoration theme that is especially reserved for that purpose? The problem I see with that though is applications that implement CSD, that could maybe fake the look of the window decoration, so this does not seem like the best idea right?

I think you outlined the problem with that already: it's easy to fake with CSD. Also the problem is "how should a user know that a window cannot do that".

kdeuserk wrote:A plasma input dialog seems like a really good option imho, though what implications does this have on the portability of applications? Will there be a unified protocol for all applications, no matter if they come from the gnome camp or the KDE camp? What about those applications on other platforms?

What I'm most interested in is the polkit authentication dialog. That is from the architecture already multi-platform aware. So on Plasma it would pick our dialog, on GNOME or something else it would use the native dialog. Similar for kwallet. And in the end: if our solution is not available, it could fallback to a good old dialog.

mgraesslin wrote:I'm especially interested in colomar's opinion on the topic.

A usable security question is brought to a usable security researcher, I guess there is no way around working on this
I've already asked my colleague who is currently working on a project where he designs security-related user interfaces if he'd like to join me working on this.
What is the timeframe for the design? Depending on that, we can provide anything from providing input off the top of our heads to a full-blown scientific project.

colomar wrote:What is the timeframe for the design? Depending on that, we can provide anything from providing input off the top of our heads to a full-blown scientific project.

there is no time-pressure on it.

mgraesslin wrote:

colomar wrote:What is the timeframe for the design? Depending on that, we can provide anything from providing input off the top of our heads to a full-blown scientific project.

there is no time-pressure on it.

Awesome! Then we can get crazy-sciency on that, with proper literature and everything
Please, all others who read this: That doesn't mean you should not brainstorm for ideas, of course We will support the design with scientific research, but that doesn't replace creativity, of course.

This probably sounds stupid but is there any known case of an attack where an attacker showed a dialog to a user to make him enter his local user or administrator password? It sounds quite useless.

scummos wrote:This probably sounds stupid but is there any known case of an attack where an attacker showed a dialog to a user to make him enter his local user or administrator password? It sounds quite useless.

No, but we need to have our software secure before we have a situation as in Windows ten years ago. But better ask Snowden

Polkit btw. is pretty dangerous in that regard as if you fake the dialog and you get the password you have root priviledges, so a simple exploit to get on the system can be used to become root.

While we're at it, I'd like to redesign the Polkit dialog anyway, as in its current form it is very unclear to average users what exactly happens.

We currently have a "Dim Screen for Administrator Mode" effect.

The idea of this seems fine I think, it keeps some familiarity both with what we've done prior and other OSs.

It probably shouldn't be disable-able and ideally needs to be a bit more advanced than just comparing the windowClass (no idea what though)

david_edmundson wrote:We currently have a "Dim Screen for Administrator Mode" effect.

The idea of this seems fine I think, it keeps some familiarity both with what we've done prior and other OSs.

It probably shouldn't be disable-able and ideally needs to be a bit more advanced than just comparing the windowClass (no idea what though)

The not disable-able part is tricky (as it's just a plugin in KWin which can be disabled through the architecture). The making it more advanced: that's easier. windowClass was X11 world, in Wayland we have way better possibilities.

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.

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.

What should be done instead? Waiting for applications to implement proper sandboxing? That might take ages, or have there been any attempts to systematically sandbox KDE applications independent from downstream? I think we have to start somewhere. Imho sandboxing should become standard even on desktops. I see a lot of political issues arising though: What MAC system to use? Apparmor/SELinux/Smack/TOMOYO (different distributions prefer different systems and afaik both mentioned cannot be used parallel cause they are all LSM modules.)
The Gnome guys aim for sandboxing too and I think there should be as much collaboration between different projects than possible in that regard.

kdeuserk wrote:What should be done instead?

You responded on the wrong thread and the "secure fullscreen" thread moved to "sign the good dialog".
Whether or not we'll ever have perfect sandboxing (what if I make KFooBar look like KMyMoney...?) is a matter of it's own but until then, signing trustable clients is less annoying than telling the user that 99% of his applications cannot be trusted (regardless of the displayserver and whatnot)

luebking wrote:You responded on the wrong thread and the "secure fullscreen" thread moved to "sign the good dialog".

Damn, you are right, sorry for the inconvenience. Maybe some moderator wants to delete both of mine and your comment?

I'd refer back to my post in the full-screen topic; Show the users picture, print their name, and keep it full-screen.

I think if the system is asking for your password, it should be considered "important" at all times and do a full screen-dim. On a day-to-day basis, I don't think too many things ask for passwords, and when they do they're usually the focus anyway. Plus, if we keep the security screen consistent then users will have more trust in it. Also, with the full-screen password request dialog, applications will have a harder time running afoul of the system because the *other* warning dialogue will kick in.



(although, with better spacing... And proportions...)