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 525574 - gnome-keyring-daemon does not honor constrained ssh identities
gnome-keyring-daemon does not honor constrained ssh identities
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: 2.28
Assigned To: Stef Walter
GNOME keyring maintainer(s)
: 550751 559378 593509 658815 (view as bug list)
Depends on: 775981
Blocks:
 
 
Reported: 2008-04-01 15:59 UTC by Sebastien Bacher
Modified: 2018-03-10 05:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Constrained identities + auto destruct + thread timers (38.94 KB, patch)
2009-07-16 03:15 UTC, Stef Walter
none Details | Review
Constrained lifetime SSH identities, auto destruct objects, thread timers (41.56 KB, patch)
2009-07-18 18:38 UTC, Stef Walter
committed Details | Review

Description Sebastien Bacher 2008-04-01 15:59:23 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."
Comment 1 John Hernandez 2008-04-28 22:45:01 UTC
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.
Comment 2 Stef Walter 2008-09-07 14:46:31 UTC
*** Bug 550751 has been marked as a duplicate of this bug. ***
Comment 3 Stef Walter 2008-12-11 20:46:34 UTC
*** Bug 559378 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Clasen 2009-06-11 17:01:04 UTC
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."
Comment 5 Vincent Untz 2009-06-20 16:47:37 UTC
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?)
Comment 6 Daniel Kahn Gillmor 2009-06-20 22:35:45 UTC
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.
Comment 7 Vincent Untz 2009-06-20 22:53:44 UTC
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.
Comment 8 Daniel Kahn Gillmor 2009-06-20 23:08:40 UTC
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.
Comment 9 Stef Walter 2009-06-26 14:58:34 UTC
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...
Comment 10 Stef Walter 2009-07-16 03:15:15 UTC
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.
Comment 11 Stef Walter 2009-07-18 18:38:34 UTC
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.
Comment 12 Stef Walter 2009-07-18 18:39:26 UTC
Anyone interested, please test that this works as expected, and report any problems as separate bugs. 
Comment 13 Daniel Kahn Gillmor 2009-07-19 23:53:54 UTC
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.
Comment 14 Stef Walter 2009-07-20 00:44:54 UTC
"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!
Comment 15 Stef Walter 2009-07-20 00:55:40 UTC
Whoops, I meant: 'contribute *towards* a solid + secure way...'
Comment 16 Stef Walter 2009-08-30 00:03:02 UTC
*** Bug 593509 has been marked as a duplicate of this bug. ***
Comment 17 Stephen Warren 2009-08-30 02:29:36 UTC
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.
Comment 18 Stef Walter 2009-08-30 04:14:29 UTC
Good use case. Reopened.
Comment 19 Stef Walter 2011-09-13 05:54:42 UTC
*** Bug 658815 has been marked as a duplicate of this bug. ***
Comment 20 Stef Walter 2016-12-12 13:00:17 UTC
 gnome-keyring should just wrap stock ssh-agent to solve this problem:

https://bugzilla.gnome.org/show_bug.cgi?id=775981