GNOME Bugzilla – Bug 574315
"Unlock Private Key" dialog mysteriously refers to "an application"
Last modified: 2021-06-18 10:40:10 UTC
the bug has been opened on https://bugs.launchpad.net/bugs/246185 "Several times after I log in, an "Unlock Private Key" dialog pops up. The dialog says something like "An application is trying to access the private key 'id_rsa', but it is locked", and asks me to enter my passphrase. (I'm not sure of the exact wording, because while this dialog is open I can focus other windows but not type into them, and nor am I allowed to take a screenshot.) This question is useless, because it doesn't identify the application that wants to access my key. It should gave the .desktop name of the application if there is one, or the name of the binary otherwise. ... There must be a way to state which app this wants otherwise GNOME Keyring is pretty insecure."
Nope. It's the desktop that's is pretty insecure. http://live.gnome.org/GnomeKeyring/SecurityPhilosophy We should remove the 'An application" stuff all together, or move it somewhere less conspicuous. This change can't be made right now because of string freeze in GNOME.
Stef Walter commented this issue with "This change can't be made right now" - but what's the status of this problem today, soon two years later? IMHO this issue is a major security problem, as Gnome is educating the user to just click 'OK', without giving him any information whatsoever on which to base her decision. It even proposes to unlock the keyring automatically whenever the user logs in! Does that mean that any and all applications will have access to the users secrets afterwards? This seems like a major security desaster waiting to happen. It reminds of Windows' attitude of constantly harrassing the user with meaningless modal prompts with the net effect that the user will learn to just click-away 'OK' whatever dialog that pops up. That's definitively not a standard for Gnome to strive for.
Developer comments on these questions would be appreciated. It seems many users are concerned about security and want to do things "the right way", we just don't know how. http://unix.stackexchange.com/questions/2009/how-can-i-tell-which-application-is-asking-for-access-to-gnome-keyring-seahorse http://askubuntu.com/questions/21645/an-application-asks-to-unlock-the-keyring-on-startup-but-it-doesnt-say-which-on https://bugs.launchpad.net/gnome-keyring/+bug/246185 https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/575877
The snide remarks about 'reminds me of windows' sounds a bit trollish, but I'll ignore that... Please read this carefully first: http://live.gnome.org/GnomeKeyring/SecurityPhilosophy On the linux desktop today (on nearly all distros) all applications run in a single security context. That means that from a security perspective there is no difference between code running in one program, and code running in another. There is interesting work which is working to solve this problem, for example SeLinux, rewriting graphics (removing/changing X). Then there's the signed applications on the mobile linux stacks which obviously nicely identify one application from another. At this point putting up a label for which application is accessing the secret isn't that easy, and it's very hard to get it completely right. It would be nice to get this working, but unless someone pitches in with a plan/code, it's currently at a lower priority than other gnome-keyring work.
I understand the complications with this particular issue. What I think would be most helpful is the addition of a function to determine if the keyring is already unlocked. The applications then trying to access the keyring could be required to emit their own dialogs about needing access to the keyring to identify themselves to the user. This would allow gnome-keyring manager to keep the API exactly the same, not have to do anything complicated with trying to identify the caller, and offload the dialog implementation to the project that needs access to the keyring. If the "is keyring unlocked" functionality already exists and I am overlooking it, that is my mistake. Maybe I am just finding a lazy solution, but this is the direction I would take.
Do you mean each application should unlock the keyring, rather than unlocking once for the whole desktop?
Not really. I was more stating a possible solution for the individuals that are complaining about auto-login and not wanting to add keyring unlock to their login launchers (this is most of what I see on all the bug report threads). For some reason, "add a script to your login that does this" is deemed an inadequate solution (How do they complain about not identifying the application trying for keychain being insecure and still use autologin?) I think most of the complaints I have seen stem from the unlock box not having an identifier instead of the more far reaching implication of a one time unlock. I understand both issues, but I think the complaints about the latter are either far less vocal or unclear (despite **possibly** being much more valid). I was only making a suggestion that there be an "is the keyring unlocked" routine to quell the "I can't tell which application wants the keyring" This might help by giving third party developers a way to check "if locked - do issue dialog /me is about to try and unlock the keychain - endif - try and access keychain (results in the already existing dialog to unlock or not). Does that clarify what I meant to say? If what I was trying to say is still unclear, that's my mistake. If there is current work on per application access to the keychain, that is a much more secure but complicated approach. Thank you for your time.
*** Bug 616801 has been marked as a duplicate of this bug. ***
OK. So the major use case for identifying the requesting application is that users want to only provide secrets to "trusted" applications. You've explained why that isn't well supported now in general in Linux. Bummer.... But there is another use case: users who want to get rid of or re-configure unidentified applications that ask for secrets in annoying ways. Can you provide any workaround tips here for folks just trying to identify, perhaps after the dialog box, or via debugging in anticipation of the dialog box, the process or application that is most likely making the request? For this use case we would just clarify that the user should beware that malware could spoof things and lead to the wrong answer, or whatever. Would it help to look at dbus messages, or use some sort of process accounting, or ....?
(In reply to Stef Walter from comment #4) > Please read this carefully first: > http://live.gnome.org/GnomeKeyring/SecurityPhilosophy Link updated: https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy > At this point putting up a label for which application is accessing the > secret isn't that easy, and it's very hard to get it completely right. It > would be nice to get this working, but unless someone pitches in with a > plan/code, it's currently at a lower priority than other gnome-keyring work. I do not agree that it is not high priority. It is really annoying to not know what is requesting what. I also do not see how the above security philosophy is affected by this. It is probably not the forum to discuss here in detail all the aspects of this. So I ask if you can escalate this issue and discuss in a team and make a decision. Thanks Thomas
The mailing list desktop-devel-list@gnome.org is a good place to discuss this. I wouldn't be against a contribution to remedy this problem. The problem trancends gnome-keyring however. The policy kit privilege escalation dialogs have the same issue. They do not refer to the application requesting the privilege (at least in GNOME).
> The policy kit privilege escalation dialogs have the same issue. They do not > refer to the application requesting the privilege (at least in GNOME). The polkit-gnome-authentication-agent has a "Details" spoiler which, if opened, shows details about the performed action (which are a bit cryptic, but still much better than nothing): http://i.imgur.com/V0YykYm.png
*** Bug 784269 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/ Thank you for your understanding and your help.