Kver wrote:I think if the system is asking for your password, it should be considered "important" at all times and do a full screen-dim.

a) this would determine the users workflow
b) it's actually providing less information about what requires priv escalation than a modal dialog (which is attached to the dimmed window)

Kver wrote:Plus, if we keep the security screen consistent then users will have more trust in it.

I totoally agree that there should be one kind of security dialog that is used on
* login (ideally)
* priv escalation
* screen unlocking

Also because there're high demands on the implementation security in order to trust this dialog.

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

This can be handled easily by the WM:
once the (known) password input dialog has the input focus, it's not given anywhere unless the user actively passes it on.

luebking wrote:

Kver wrote:I think if the system is asking for your password, it should be considered "important" at all times and do a full screen-dim.

a) this would determine the users workflow
b) it's actually providing less information about what requires priv escalation than a modal dialog (which is attached to the dimmed window)

Good points, especially the fact that it wouldn't illustrate what's specifically making the request. ++

luebking wrote:

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

This can be handled easily by the WM:
once the (known) password input dialog has the input focus, it's not given anywhere unless the user actively passes it on.

Also, ++.

Kver, your mockup has a slight usability problem: one cannot switch to a browser to search on "why is it doing that?" and "what did just trigger that?". It's kind of the same problem the nagging dialogs in Windows caused and why people disabled it. If you want to not act immediatelly you have to use cancel and then it's difficult to get back there.

I agree, Windows' solution for this is bad. Especially since often some background process kicks in (Java Updater, yeeeah!) and totally interrupts your workflow with a dialog you're not interested in at all currently.

A background process suddenly asking for a password is bad in general, because it is very confusing (especially the first few times a process does that) for the user.
Even if we can tell which application asks for the password and why, it still has a too strong element of surprise.
Therefore the question is: Is there any way we can prevent password dialogs popping up without user interaction? This might actually be the single biggest step to reduce user confusion with password dialogs.

colomar wrote:Therefore the question is: Is there any way we can prevent password dialogs popping up without user interaction? This might actually be the single biggest step to reduce user confusion with password dialogs.

Difficult as applications react on network status (e.g. suddenly connected to the Internet) and then start connecting and need passwords.

An idea I have is to put asking for password it into Plasma's notification area. So it would just expand the systray, but otherwise not interrupt the work.

mgraesslin wrote:

colomar wrote:Therefore the question is: Is there any way we can prevent password dialogs popping up without user interaction? This might actually be the single biggest step to reduce user confusion with password dialogs.

Difficult as applications react on network status (e.g. suddenly connected to the Internet) and then start connecting and need passwords.

Hm. I'd understand if applications would need to unlock a wallet when connecting, but not if they ask for the root password. KWallet dialogs could be faked as well, of course, but that's a separate story from Polkit dialogs to me.

An idea I have is to put asking for password it into Plasma's notification area. So it would just expand the systray, but otherwise not interrupt the work.

Indeed. This is also what the HIG would suggest since automatic connections are usually not part of the user's current workflow. If the user connects manually, things are different.
Again, though, this should only apply to wallet unlocking, not to Polkit dialogs. No application should start an action that needs root privileges by itself. Ever.

colomar wrote:KWallet dialogs could be faked as well, of course, but that's a separate story from Polkit dialogs to me.

However, contrary to polkit root password dialogs, imo for an attacker it would actually make sense to fake those: you get access to the user's email or bank account password. The root password dialog thing is simply a quite bad way of privilege escalation when you already have local code execution, which I still don't see as a terribly powerful tool compared to how many possibilities for privilege escalation -- or other ways to spread malice -- there probably are on an average desktop system (my root password is five times in my shell history for example, simply because I mistyped su or something). Or, to put it differently: What evil things can you do as root on a typical person's computer which you can't do by just executing code as the user, which you obviously can do already?
Oh, let's not forget password-less sudo by default (which nobody on earth disables) on ubuntu systems (or did they remove that now?).

Still, I guess since the same design could be used for kwallet as well, this is a very similar issue, so sorry to distract

kwallet is (so far?) completely insecure anyway - as soon as decrypted, every process w/ user rights has access to the entire wallet.

while malicious user access already means trouble enough, if you ever gain root access, the game is over. you can change random system binaries and access all harware - you can watch any user, any time, on any action. all security mechanisms discussed here are simply void at that point.

global NOPASSWD sudo is simply insane and of course means that any attempt to secure the users password are pointless. ideally, only a limited set of commands is whitelisted for sudo, so that you can -hopefully- not reach a rootshell by the users password. this is however unrealistic for "normal" setups ("sudo make install" anybody?)

i think, background processes requesting priv escalation are usually the system auto-updaters of the distro, and that is *really* **** by design.
i do completely understand the demand to invoke the "current" (ie. on distros w/ auto-update: "the") user, but even if that needs protection beyond a "now?" dialog, it should not be the root or users password, but a shared "secret" among users (eg. the password for "distroupdater", the user with passwordless sudo access to "apt-get upgrade")

in any case: if sth. requires priv escalation or a password for another reason, it better should *always* show/have a window to give the user some context on the requirement - i see the kmail/akonadi issue, but it could show some sort of splashscreen.
given the current security of kwallet, i however just decrypt it on login (w/o any additional password request)

luebking wrote:kwallet is (so far?) completely insecure anyway - as soon as decrypted, every process w/ user rights has access to the entire wallet.

KWallet does have a mode where it asks any time a non-whitelisted applicaiton accesses it. Or does that not really protect the content against unauthorized access? If so, it's dangerous snakeoil!
Not sure wha the default is for that option from our side, though.

while malicious user access already means trouble enough, if you ever gain root access, the game is over. you can change random system binaries and access all harware - you can watch any user, any time, on any action. all security mechanisms discussed here are simply void at that point.

Indeed.

i think, background processes requesting priv escalation are usually the system auto-updaters of the distro, and that is *really* **** by design.

i do completely understand the demand to invoke the "current" (ie. on distros w/ auto-update: "the") user, but even if that needs protection beyond a "now?" dialog, it should not be the root or users password, but a shared "secret" among users (eg. the password for "distroupdater", the user with passwordless sudo access to "apt-get upgrade")

Agreed. Either an updater only notifies about available updates and lets the user choose to install them (my preferred method because it leaves the user in control), or it does indeed update completely automatically. Asking the user to provide the root password for an action that's supposed to happen automatically is completely unacceptable from a usable security standpoint, as it does not allow the user to make an informed choice.

in any case: if sth. requires priv escalation or a password for another reason, it better should *always* show/have a window to give the user some context on the requirement

+1

colomar wrote:

luebking wrote:kwallet is (so far?) completely insecure anyway - as soon as decrypted, every process w/ user rights has access to the entire wallet.

KWallet does have a mode where it asks any time a non-whitelisted applicaiton accesses it. Or does that not really protect the content against unauthorized access? If so, it's dangerous snakeoil!

it doesn't have an authentication mechanismn. If you tell it "hey I'm Firefox", it will reply "cool, you are Firefox: here are your passwords". I tested that with the former KWallet maintainer sitting next to me, reading out the wallet just on the command line. In addition the communication is via D-Bus which is not very secure per se.

mgraesslin wrote:it doesn't have an authentication mechanismn. If you tell it "hey I'm Firefox", it will reply "cool, you are Firefox: here are your passwords". I tested that with the former KWallet maintainer sitting next to me, reading out the wallet just on the command line. In addition the communication is via D-Bus which is not very secure per se.

Uh-oh, that is dangerous! So KWallet makes it look like it's secure when in fact it isn't, therefore reducing overall security. It seems like we have to take a good look at KWallet from a security perspective, especially communicating the risks to users.

Just for the reference:

qdbus org.kde.kwalletd /modules/kwalletd open kdewallet 0 Amarok

-> gets back an <id>

qdbus org.kde.kwalletd /modules/kwalletd readPassword <id> Amarok lastfm_password Amarok

-> gets back the password

colomar wrote:So KWallet makes it look like it's secure when in fact it isn't, therefore reducing overall security.

The prompt is off by default:

_openPrompt = walletGroup.readEntry("Prompt on Open", false);

although I believe that was changed only a year ago or so (so maybe you've a setting to show it intact?)



KWallet only provides offline security, much like an encrypted home dir (or loop device) - nothing beyond that (except a GUI to "un/mount")
One could certainly encrypt communication between wallet and client, but the major hole in the wall is that really anything can feign to be anything.

Afaik[1] Linux doesn't allow userspace to see the other end of the socket, but it can certainly not be assumed as general feature on POSIX systems.
Therefore the client would have to identify itself by providing a "secret" (to gain limited access to data stored for this identification) and that "secret" would either be "stashed" in the clients code, stored plaintext on disk ... or would require a - guess what - passwort to be decrypted

[1] see eg. here
http://stackoverflow.com/questions/1189 ... connection
It's a very popular question on SO

luebking wrote:Afaik[1] Linux doesn't allow userspace to see the other end of the socket, but it can certainly not be assumed as general feature on POSIX systems.

I don't know how it works, but over a wayland connection one gets the PID, UID and GID of the connected client (see wl_client_get_credentials).