GNOME Bugzilla – Bug 681081
gpg passphrase cached forever
Last modified: 2012-08-21 06:29:36 UTC
Hi, The following bug has been reported on the Debian BTS: =====8<==== At some point gnome-keyring seemed to obey the configuration asking it to stop caching passphrases after a while. It no longer does. $ gsettings list-recursively org.gnome.crypto.cache org.gnome.crypto.cache gpg-cache-authorize false org.gnome.crypto.cache gpg-cache-method 'idle' org.gnome.crypto.cache gpg-cache-ttl 600 Yet I'm never asked for the passphrase again. =====8<==== An other person has also reported that he saw the same behavior with "org.gnome.crypto.cache gpg-cache-method 'timeout'" For more information please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683655
Created attachment 220633 [details] [review] schema: Update description for gpg-cache-method * Document the various method strings that can be present here
Created attachment 220634 [details] [review] gpg-agent: Hook up the TTL cache option * So that when the gsettings gpg-cache-method is 'idle' or 'timeout' we use gpg-cache-ttl to control how long the passphrase is cached for. * This is a regression from 3.3.x
Would it be possible to try out the above patch and see if it fixes the problem for you?
I tested your patch with the "idle" method but it looks like "idle" is handled like "timeout". It does not reset the cache period everytime that you access the GPG key. But at least there's again some automatic expiration because after the delay I had to re-enter my passphrase (as expected). (BTW older versions had an option to require a confirmation before allowing the use of the GPG key, this was a nice option, it would be nice to have it back too)
In fact, reading the code I believe that the passphrase is now always cached for gpg-cache-ttl seconds as soon as gpg-cache-method is different from always. This means that the semantics of gpg-cache-method="session" (the default) changed. And gpg-cache-ttl defaults to 300 (i.e. a non-zero value) so it affects everybody automatically. (For reference I applied the patches on top of gnome-keyring 3.4.1 and that's the code I have been reading)
Created attachment 220674 [details] [review] gpg-agent: Hook up the TTL cache option * So that when the gsettings gpg-cache-method is 'idle' or 'timeout' we use gpg-cache-ttl to control how long the passphrase is cached for. * This is a regression from 3.3.x
Created attachment 220675 [details] [review] secret-store: Mark a secret item as 'used' when accessed * This makes the gpg-agent idle feature work correctly
Thank you for the review :) Indeed, both of those were broken. Could you test the two new attached patches? Off hand, I believe that the code surrounding these patches hasn't changed that much since 3.4.x and that shouldn't be a problem.
It seems to work for me with those two patches. I tested the correct behaviour of "idle", "timeout" and "session". Following the earlier code review, I still wonder what's the point of the gcr_prompt_get_choice_chosen() check since the prompt shown to the user (by GNOME Shell?) has no options at all to allow permanent storage of the passphrase...
(In reply to comment #9) > Following the earlier code review, I still wonder what's the point of the > gcr_prompt_get_choice_chosen() check since the prompt shown to the user (by > GNOME Shell?) has no options at all to allow permanent storage of the > passphrase... It does when the 'login' keyring is already unlocked, and thus the daemon is able to store the passphrase permanently in the login keyring.
(In reply to comment #4) > (BTW older versions had an option to require a confirmation before allowing the > use of the GPG key, this was a nice option, it would be nice to have it back > too) Although it makes one feel good, this doesn't actually add any security. Any application can click the button via X to allow use of the GPG passphrase.
(In reply to comment #11) > Although it makes one feel good, this doesn't actually add any security. Any > application can click the button via X to allow use of the GPG passphrase. Only if you let them use XTEST, AFAIK...
(In reply to comment #12) > (In reply to comment #11) > > Although it makes one feel good, this doesn't actually add any security. Any > > application can click the button via X to allow use of the GPG passphrase. > > Only if you let them use XTEST, AFAIK... Which is always enabled for accessibility, no? Plus XSendEvent lets an application send an event too. In addition there's no way to securely display the name of the application that wants to access the password (it'll always be gpg). All that said, maybe it's not impossible after all... If someone wants to invest time and effort to implement this securely then I'd be willing to review patches. But I'm not really that interested in spending a lot of time for no real security gain, so it needs to actually perform its use case securely. For example, see bug #525574. In that case with ssh, it does make sense to implement prompting because of SSH agent forwarding. Although it seems that nobody has had time to actually do it.
Attachment 220633 [details] pushed as 3de11dd - schema: Update description for gpg-cache-method Attachment 220674 [details] pushed as 111a132 - gpg-agent: Hook up the TTL cache option Attachment 220675 [details] pushed as 979bf3c - secret-store: Mark a secret item as 'used' when accessed
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Although it makes one feel good, this doesn't actually add any security. Any > > > application can click the button via X to allow use of the GPG passphrase. > > > > Only if you let them use XTEST, AFAIK... > > Which is always enabled for accessibility, no? Plus XSendEvent lets an > application send an event too. In addition there's no way to securely display > the name of the application that wants to access the password (it'll always be > gpg). > Well you should only enable XTEST if you want random apps to be able to send random keypresses to others. So no it's not "always enabled". And most apps ignore events with the send_event bit set.
This issue was assigned CVE-2012-3466 as per: http://www.openwall.com/lists/oss-security/2012/08/09/2
Since this is a (low impact) security issue, I've taken a look at which stable releases are affected: * 3.4.1 * 3.4.0 The following releases do not have this issue, although they have a separate non-security issue. The 'idle' setting is not respected, and they act like 'timeout' instead. The reason this is not a security problem is because the erroneous behavior is more strict than the expected behavior. * 3.2.2 * 3.2.1 * 3.2.0
gnome-3-4 branch patches for this issue: 51606f299e5ee9d48096db0a5957efe26cbf7cc3 5dff623470b859e332dbe12afb0dc57b292832d2
(In reply to comment #17) > Since this is a (low impact) security issue, I've taken a look at which stable > releases are affected: > > * 3.4.1 > * 3.4.0 > > The following releases do not have this issue, although they have a separate > non-security issue. The 'idle' setting is not respected, and they act like > 'timeout' instead. The reason this is not a security problem is because the > erroneous behavior is more strict than the expected behavior. > > * 3.2.2 > * 3.2.1 > * 3.2.0 Interestingly, i can see this issue on older versions of gnome-keyring as well. I am able to reproduce this with gnome-keyring-2.28
Could you please include specifics of how you see this issue in 2.28. gnome-keyring had no gpg-agent, seahorse had the agent at that point. Are you sure you're using the right settings? I think these settings used to be controlled through the seahorse settings.
Hi Stef, Looks like false alarm, cache-ttl is in minutes, i thought it was in seconds :)