After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 574315 - "Unlock Private Key" dialog mysteriously refers to "an application"
"Unlock Private Key" dialog mysteriously refers to "an application"
Status: RESOLVED OBSOLETE
Product: gnome-keyring
Classification: Core
Component: prompting
git master
Other Linux
: Normal normal
: 2.28
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
: 616801 784269 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-03-05 22:18 UTC by Sebastien Bacher
Modified: 2021-06-18 10:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2009-03-05 22:18:19 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."
Comment 1 Stef Walter 2009-03-07 05:38:52 UTC
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.
Comment 2 Tomas Pospisek 2011-01-25 19:53:09 UTC
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.
Comment 4 Stef Walter 2011-02-04 01:42:32 UTC
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.
Comment 5 aking1012 2011-02-07 15:26:12 UTC
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.
Comment 6 Stef Walter 2011-02-09 18:11:03 UTC
Do you mean each application should unlock the keyring, rather than unlocking once for the whole desktop?
Comment 7 aking1012 2011-02-10 14:32:26 UTC
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.
Comment 8 Stef Walter 2012-03-15 09:29:43 UTC
*** Bug 616801 has been marked as a duplicate of this bug. ***
Comment 9 Neal McBurnett 2014-10-11 04:17:17 UTC
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 ....?
Comment 10 Thomas Hartwig 2015-08-05 10:59:00 UTC
(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
Comment 11 Stef Walter 2015-08-05 11:10:31 UTC
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).
Comment 12 Photon 2017-04-11 09:42:14 UTC
> 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
Comment 13 Florian Müllner 2017-06-28 18:08:09 UTC
*** Bug 784269 has been marked as a duplicate of this bug. ***
Comment 14 André Klapper 2021-06-18 10:40:10 UTC
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.