LibWSM: Wayland Security Modules For Better Wayland Security

[TheBlackCat]

How could a "Security Module" of the Display/Windowing Server actually guarantee that. What is, if somebody perfectly forges such a dialog box...

As erendorn, Almindor, Steve DL, and I have explained, the idea is that the compositor would use visual cues to show that the dialog is legitimate, such as dimming, blurring, or desaturating everything but the dialog. Even if a malicious app could duplicate the appearance of the dialog itself, it would not be able to duplicate these visual cues (because it would be prevented from seeing the desktop and other windows).

There are more details in the four posts immediately before yours.

[curaga]

What forces application Z to use that? There's a huge amount of applications with their own password dialogs, changing them all to get the legitimate wayland cues seems like a lot of work.

[TheBlackCat]

What forces application Z to use that? There's a huge amount of applications with their own password dialogs, changing them all to get the legitimate wayland cues seems like a lot of work.

You can't force them to use it for their own internal passwords, but generally getting root access or accessing your keyring/wallet has to go through a standard, DE-provided dialog anyway, so there shouldn't be any additional work on the part of applications for those cases.

[curaga]

Playing devil's advocate, if app X has the cues but app Y doesn't, won't the user be easily confused? Malware pretending to be app X throws a dialog up, it would normally have the cues, but the user won't notice because many other apps don't.

[erendorn]

Playing devil's advocate, if app X has the cues but app Y doesn't, won't the user be easily confused? Malware pretending to be app X throws a dialog up, it would normally have the cues, but the user won't notice because many other apps don't.

Privilege escalation (system passwords) shouldn't never go through the application (always called by OS or DE API).

For in-app passwords, well you cannot make unspoofable dialogs (they would look the same for all apps), but, as both the application input and output are private, it is very hard for a rogue application to intercept a credible situation for asking for a password of an other app. And there are other signs, if the dialog moves with the main window when you move the main window, then it's necessarily legitimate (cursor movements are not shared to other windows, windows positions are private).

[TheBlackCat]

Playing devil's advocate, if app X has the cues but app Y doesn't, won't the user be easily confused? Malware pretending to be app X throws a dialog up, it would normally have the cues, but the user won't notice because many other apps don't.

No apps should ask for root permissions using their own dialog. Do you know any that do? As for user passwords, anything asking for your wallet/keyring password should be using the wallet/keyring dialog.

So the only applications that won't be are those using their own internal password store. But this shouldn't be that confusing, since only dialogs asking for system passwords (root or wallet/keyring) will be using these effects. So system password->cues, app password->no cues.

And which applications do you actually use that have their own dialog? The only one I use is firefox. Every other application either goes through polkit, kwallet, or keyring. From what I can see even chrome supports wallet/keyring integration.

[curaga]

Well I'm not using a DE, so nothing in my system uses a keyring/wallet/keystore/whatever.

If it's indeed restricted to gksu and other similar root wrappers, and is used consistently, then I don't see an issue. But if some apps are allowed to use it for their own passwords, that undermines the security of the whole effect.

[erendorn]

Well I'm not using a DE, so nothing in my system uses a keyring/wallet/keystore/whatever.

If it's indeed restricted to gksu and other similar root wrappers, and is used consistently, then I don't see an issue. But if some apps are allowed to use it for their own passwords, that undermines the security of the whole effect.

Well exactly, so I doubt any DE will offer a function for creating custom dialogs that look just like the priviliedged security ones
Note that Windows does exactly that, so there are examples in wide scale use to build upon.

[Steve DL]

It's cool to see some discussion on our talk :-) You guys and girls should not hesitate to ask us questions or criticise, it will eventually help improve LibWSM!

What forces application Z to use that? There's a huge amount of applications with their own password dialogs, changing them all to get the legitimate wayland cues seems like a lot of work.

All app-requiring passwords should be proposing the use of a password store. I hate to type my password in my IM client but there's no way I would let it "store" my password. It also makes a lot of sense to bugger developers for this because eventually Linux apps will be sandboxed and that means password stores will be able to store your passwords even more securely (and maybe sync them across your devices?). If devs need a cross-platform way to do so they can look at PPassKeeper built by Martin :-) http://www.mupuf.org/project/ppasskeeper.html And if anyone thinks there should be a cross-desktop protocol for password handling, I couldn't agree more and you should really write to the FreeDesktop Mailing List and the GNOME, KDE and Unity devs about this :-)

You can't force them to use it for their own internal passwords, but generally getting root access or accessing your keyring/wallet has to go through a standard, DE-provided dialog anyway, so there shouldn't be any additional work on the part of applications for those cases.

Yup, we're only designing a UI for system-managed authentication. That includes a number of tasks as explained on my blog, but not app auth UIs. People might agree that it'd be a good idea to let apps use this to authenticate their users. I would agree only on the condition that these apps use the DE's password store to store passwords. I will advocate for compositor developers to use a unique capability/permission for both actions.

Playing devil's advocate, if app X has the cues but app Y doesn't, won't the user be easily confused? Malware pretending to be app X throws a dialog up, it would normally have the cues, but the user won't notice because many other apps don't.

If apps didn't insist on making you type passwords they wouldn't have this problem :-) Unfortunately we can't do much about this.. Letting apps use the system UI for authenticating also means that this UI is much more commonly seen by the user and they're more used to typing passwords in it. This means that users would get habituated and peripheral elements of security would be less noticed over time, making a "realistic" spoof attack more likely to succeed (e.g., putting the wrong number of blurry windows or windows with the wrong content in the background when attacking a UI that uses blurry windows).

Ideally apps would be able to benefit from this facility but use it very sparingly by entrusting the OS with their credentials. This means a consistent user experience, secure password storage, harder attacks and not too much auth UI habituation.

No apps should ask for root permissions using their own dialog. Do you know any that do? As for user passwords, anything asking for your wallet/keyring password should be using the wallet/keyring dialog.

So the only applications that won't be are those using their own internal password store. But this shouldn't be that confusing, since only dialogs asking for system passwords (root or wallet/keyring) will be using these effects. So system password->cues, app password->no cues.

And which applications do you actually use that have their own dialog? The only one I use is firefox. Every other application either goes through polkit, kwallet, or keyring. From what I can see even chrome supports wallet/keyring integration.

Ah, forgot to mention Polkit! Ideally what we envision for auth UIs would be implemented as the polkit agent of the DE you run. We'll see what happens in the coming years though.

Well exactly, so I doubt any DE will offer a function for creating custom dialogs that look just like the priviliedged security ones
Note that Windows does exactly that, so there are examples in wide scale use to build upon.

Letting untrusted apps create custom trusted permission UIs would be quite stupid but you never know!

I don't have an issue however with apps using a trusted auth UI for users to type a password, and for that UI to immediately store it in the keyring and either send it to the app or send a hash of it or perform an auth check on behalf of the app. The more often we can use this to actually prevent apps from seeing our (app) passwords in cleartext, the better security we obtain.


If people want more information they can now watch the talk on YouTube.

As far as I'm concerned, the next few topics of FOSS work/conversation that I'd like to do/have are:

• continuing LibWSM. Anybody with feedback (especially negative) should drop us a mail!
• building a UI embedding protocol...
• designing a flexible protocol for 2-factor auth so the out-of-bands feedback loop can be built and people can actually authenticate securely

If you have any ideas or want to help us, do get in touch!

[smitty3268]

But if some apps are allowed to use it for their own passwords, that undermines the security of the whole effect.

Apps can't use it for their own passwords, because that would defeat the entire point. If an app can do it, then so can malware. The idea is to restrict it to just the system only, and apps can only do things within themselves, without touching anything else running.