GNOME Bugzilla – Bug 525574
gnome-keyring-daemon does not honor constrained ssh identities
Last modified: 2018-03-10 05:08:59 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/209447 "The ssh-agent honors adding constrained identities -- where such constraints may be either: * Require confirmation each time the agent allows the identity to be used. * A maximum lifetime for the identity. The gnome-keyring-daemon is a replacement for the ssh-agent in Hardy Heron, but does not support those constraints. If the user issues: ssh-add -c or ssh-add -t <time value> The identities will be added without those constraints. This is especially important in some uses of the ssh-agent, such as ssh-agent forwarding, where the usage of the agent can not be considered secure without the confirmation constraint."
As a workaround, you can revert to using ssh-agent: Launch gconf-editor, apps/gnome-keyring/daemon-components, uncheck ssh. Restart X. ssh-agent should start.
*** Bug 550751 has been marked as a duplicate of this bug. ***
*** Bug 559378 has been marked as a duplicate of this bug. ***
https://bugzilla.redhat.com/show_bug.cgi?id=498112 is another downstream bug that talks about missing handling of constraints: "ssh-add -c should, according to the man page, require confirmation before using the cached key. This works in RHEL5, but not in rawhide."
Stef: looking at this. I don't know the code well, so I guess I need help :-) How do you think it should be implemented: + add some attributes to the GP11Object key objects via gp11_object_set() and retrieve the attributes when needed. We'd need to define new attributes in pkcs11/pkcs11g.h. + maintain a simple list of keys for each constraint in the agent session, and check that list when needed. (so the question is: do we embed the constraint data in the object or do we want to keep it external?)
I don't know how you want to implement the constraint internally, but: Any code which acts as an ssh-agent is a component in a serious security toolkit. In any serious security toolkit, if the current implementation cannot support (or understand) a requested constraint associated with sensitive material (e.g. secret key material) from the user, it should *not* silently ignore the constraint and proceed to import the sensitive material. If the implementation is at all in doubt, it should securely discard any associated sensitive material and indicate failure. The fact that this bug has been open for over a year without this basic precaution really makes me worry about GNOME's commitment to providing its users with reliably secure tools. Please implement the basic sane response to unimplemented requests first, then try to figure out how to support various requests later. There are real users relying on your code today who are currently vulnerable.
Daniel: when I do "ssh-add -c" or "ssh-add -t 1000", then I get SSH_AGENT_FAILURE printed. This sounds like it works fine. And then the identity gets added (which is probably what's wrong in your opinion). ssh-add does this: if (ssh_add_identity_constrained(ac, private, comment, lifetime, confirm)) { fprintf(stderr, "Identity added: %s (%s)\n", filename, comment); ret = 0; if (lifetime != 0) fprintf(stderr, "Lifetime set to %d seconds\n", lifetime); if (confirm != 0) fprintf(stderr, "The user has to confirm each use of the key\n"); } else if (ssh_add_identity(ac, private, comment)) { fprintf(stderr, "Identity added: %s (%s)\n", filename, comment); ret = 0; } else { fprintf(stderr, "Could not add identity: %s\n", filename); } Thererfore, if adding the identity with a constraint doesn't work, ssh-add blindly goes on to add the identity without a constraint (probably because the constraint stuff is not part of the RFC). So please file a bug against openssh if you think this is wrong.
Ah, i hadn't realized that was what was happening, Vincent. Thank you for clarifying what is actually going on. I feel better about gnome's ssh-agent implementation now, and a bit embarrassed that i hadn't figured this out myself! Sorry for my mistaken bad impression. I will definitely take the matter up with the openssh team.
Daniel, I agree with what you said above about indicating failure in a case where we cannot support constraints. If you find other cases where gnome-keyring fails at this in some way, please bring it to our attention. We need as many eyes on the code as possible. Vincent, I believe that the constraint data should be an internal thing. Some work has been done in this direction already. There would be two parts, it's unclear if they're related: * Support time based constraints on keys loaded with constraints via ssh-add. This is probably simpler to implement, as the key actually goes away after the time period elapses. We could think of this as a self-destruct. UI for this method, is via the -c argument of ssh-add. Some custom code in ssh-agent component. Maybe that component would do the actual destruction? * Support time based constraints on unlocking of keys originating from within gnome-keyring (including auto loaded id_rsa, id_dsa etc...). Not sure if this is related to the above, as we don't actually want to delete the keys, just relock them, so the user gets prompted again. UI for this method might be in the unlock prompt. More on this below. Not sure where the actual relocking would occur. It'd be cool if there was a way to combine the two concepts above. I've been thinking of a redesign of the unlock prompt, so that it has an expander, hiding options like: * Unlock for X minutes * Unlock for this application only. * Unlock whenever I'm logged in, etc...
Created attachment 138495 [details] [review] Constrained identities + auto destruct + thread timers Here's a patch which adds a new type of PKCS#11 object: An auto destruct object is like a ticking time bomb, which points to another PKCS#11 object. When the time elapses, it destroys both itself and the other object. The auto destruct object can in the future be used to implement timed locking of keys. Since the unlock state is a separate PKCS#11 object, it can be destroyed by the auto destruct object, essentially locking the key. The ssh-agent in the patch uses this new type of object to implement lifetime constrained identities. Also included is a thread based timer callback mechanism which isn't dependent on a main loop (since PKCS#11 modules don't have a main loop). Not tested yet, and need to build some unit tests for some of the stuff. But thought I'd post my progress here.
Created attachment 138696 [details] [review] Constrained lifetime SSH identities, auto destruct objects, thread timers Committed. Took a bit of a different approach with an optional auto-destruct attribute on each object, rather than seperate auto-destruct objects. gck/Makefile.am | 1 gck/gck-attributes.c | 97 +++++++++++++++ gck/gck-attributes.h | 8 + gck/gck-module-ep.h | 4 gck/gck-module.c | 32 ++++ gck/gck-module.h | 6 gck/gck-object.c | 120 ++++++++++++++++++ gck/gck-object.h | 8 + gck/gck-session.c | 32 ++++ gck/gck-session.h | 5 gck/gck-timer.c | 225 +++++++++++++++++++++++++++++++++++ gck/gck-timer.h | 43 ++++++ gck/gck-types.h | 1 gck/tests/Makefile.am | 2 gck/tests/test-module.c | 70 ++++++++++ gck/tests/test-module.h | 41 ++++++ gck/tests/unit-test-timer.c | 159 ++++++++++++++++++++++++ pkcs11g.h | 6 ssh-agent/gck-ssh-agent-ops.c | 74 ++++++++++- ssh-agent/gck-ssh-agent-standalone.c | 2 20 files changed, 923 insertions(+), 13 deletions(-) commit 28bf965222e58c0eae7eb76ff0143ce3b86a6fda Merge: 92251a5... d69fdd3... Author: Stef Walter <stef@memberwebs.com> Date: Sat Jul 18 18:35:22 2009 +0000 Merge branch 'auto-destruct' commit d69fdd36a70052114b8b0c4cc0efa0868709ebb0 Author: Stef Walter <stef@memberwebs.com> Date: Sat Jul 18 18:32:45 2009 +0000 Add support for lifetime constrained identities. We don't support prompt constrained identities, as security wise this is incompatible with the current X11 desktop. And currently amounts to 'security theater'. commit 274b2f5d8993e7b1b8717b7df50a4c678aa64641 Author: Stef Walter <stef@memberwebs.com> Date: Sat Jul 18 18:32:27 2009 +0000 Make standalone socket in a directory we know exists: /tmp commit ad2c0e75977c7a76c25ef27fb29b767d3c1e94ad Author: Stef Walter <stef@memberwebs.com> Date: Sat Jul 18 18:31:48 2009 +0000 Add support for auto destructing session objects. These destroy themselves after a certain amount of lifetime controlled by the CKA_GNOME_AUTO_DESTRUCT attribute. commit 10ecb163793305ceed6a3cee48f2e593daabdd20 Author: Stef Walter <stef@memberwebs.com> Date: Sat Jul 18 18:30:53 2009 +0000 Add support for parsing and storing time attributes. These time attributes follow the PKCS#11 clock format. That is: YYYYmmddHHMMSS00 16 chars commit 30d87d669ce3c17a3de5de1e065ddc09357d2170 Author: Stef Walter <stef@memberwebs.com> Date: Sat Jul 18 18:25:48 2009 +0000 Add support for thread timers. We can't use mainloop timers from PKCS#11 modules, since no mainloop runs in those modules. Thread timers all share a single thread and callback into the module at the given time.
Anyone interested, please test that this works as expected, and report any problems as separate bugs.
Is this really closed? the bug report refers to two different flavors of constraint: time limitations, and confirmation prompts. the comments in the referenced changelogs here seem to refer to the time limitation, but i see nothing about confirmation prompts. I haven't tested the new version yet to see if it handles confirmation prompts, but it doesn't sound like this concern has been addressed.
"Click OK to Continue" prompts when done on a vanilla X desktop are a good example of 'security theater'. They make people feel good, but don't actually add any security. (ie: click events can be synthesized by any application on the X desktop, thus prompts do nothing to prevent an application from using the key). Please read this the following [1]. After that if you'd like to contribute a solid + secure way to do per-use prompts, then join us on gnome-keyring-list@gnome.org [1] http://live.gnome.org/GnomeKeyring/SecurityPhilosophy All the best!
Whoops, I meant: 'contribute *towards* a solid + secure way...'
*** Bug 593509 has been marked as a duplicate of this bug. ***
Comment #14 says: > "Click OK to Continue" prompts when done on a vanilla X desktop are a good > example of 'security theater'. They make people feel good, but don't actually > add any security That's not true in all cases. Considering the case of 2 machines, where machine A running gnome-keyring is SSH'ing to machine B, yes, I can see your point. However, in the case where machine A running gnome-keyring is SSH'ing to machine B and performing ssh-agent forwarding, and then machine B SSH's to machine C using a key obtained from the SSH agent, then there is definitely a point to the Y/N prompting. A root user (admin or cracker) on machine B can trivially "attach" to the forwarded SSH agent connection on machine B, and hence can illicitly use the agent to connect to machine C. Prompting on machine A for confirmation generally prevents this, unless the admin/cracker of machine B has compromised machine A too, and spoofs the click, which is somewhat harder (especially if no X forwarding was used, or -X was used instead of -Y). Hence, I request this to be reopened. If it's not, I'll have to unmark bug 593509 as being a duplicate, since an open bug needs to exist to register the RFE.
Good use case. Reopened.
*** Bug 658815 has been marked as a duplicate of this bug. ***
gnome-keyring should just wrap stock ssh-agent to solve this problem: https://bugzilla.gnome.org/show_bug.cgi?id=775981