> > Interesting. However, isn't there a small security value in protecting
> > just the fact that you have a password stored for a particular target?
> 
> Yes possibly, but I'd assume it's of very minor value. Your typical
> system is littered with clues as to what URIs, network shares, email
> accounts, etc... have been accessed.

Still I think it _must_ be made possible for the application that created the particular keyring items to forbid its existence to be revealed by this way.

Do you have an application in mind, or is this purely theoretical?

Yes, Epiphany.

Not trying to be argumentative, but I'm not sure I understand why the existence of the uri that was authenticated is sensitive in this case. Surely the epiphany history, network traffic, caches, and many other things expose the uri more readily than its presence in gnome-keyring.

In fact couldn't a rogue process use atk and accessibility features to read the URI information from the ACL prompt (and click the 'Allow' buttons)? 

So really, to do what you demand in comment #1 gnome-keyring needs more than what it has right now. It's additional functionality not affected by this bug. You'd need to make a way for the application to store a flag with the secret that makes the process *never* let any other process list item ids, retrieve item info, or retrieve the item attributes list. 

This is outside the scope of my modifications, but if you *need* such functionality then I guess you could contribute it to gnome-keyring.

(In reply to comment #4)
> Not trying to be argumentative, but I'm not sure I understand why the existence
> of the uri that was authenticated is sensitive in this case. Surely the
> epiphany history, network traffic, caches, and many other things expose the uri
> more readily than its presence in gnome-keyring.

First, (together with the patch to make Epiphany use gnome-keyring) I'm working on a way for Epiphany not to store that info in cache or history (private mode). Also, the existence of a keyring item reveals more than just that you have visited the site: it reveals that you have an *account* there. So this is a privacy issue for me.
The network traffic is protected by other means (SSL).

(In reply to comment #5)
> In fact couldn't a rogue process use atk and accessibility features to read the
> URI information from the ACL prompt (and click the 'Allow' buttons)? 

This is an attack on the secrecy. That doesn't mean that we should just give up and not try to protect the secrecy at all; it means we should try to prevent the attack. (There might also be other attacks against gkr to try to guess whether a given secret exists, e.g. a timing attack.)
 
> So really, to do what you demand in comment #1 gnome-keyring needs more than
> what it has right now. It's additional functionality not affected by this bug.IMHO

No, you propose to enable disclosure of keyring item's existence (and their 'non-secret' attributes?) to other applications which isn't how it works now. So applications need a way to continue to protect their secrets.
In fact IMHO it should continue to be the default, also and esp. for pre-existing keyring items.

> You'd need to make a way for the application to store a flag with the secret
> that makes the process *never* let any other process list item ids, retrieve
> item info, or retrieve the item attributes list. 
> 
> This is outside the scope of my modifications, but if you *need* such
> functionality then I guess you could contribute it to gnome-keyring.

No, IMHO this is a prerequisite of accepting your proposed changes, not an independent RFE.

Btw, I'm not trying to be argumentative either, it's just that I think privacy should come first, and only at the user's explicit consent should convenience be placed first over privacy.

(In reply to comment #6)

> First, (together with the patch to make Epiphany use gnome-keyring) I'm working
> on a way for Epiphany not to store that info in cache or history (private
> mode). Also, the existence of a keyring item reveals more than just that you
> have visited the site: it reveals that you have an *account* there. So this is
> a privacy issue for me.

Interesting. But gnome-keyring needs a lot of work before such high privacy expectations are viable. For example, it does not use secure memory, secondly as I noted earlier the prompt can easily be bypassed by a malicious application.

The idea was for seahorse to manage the users passwords, this would include epiphany passwords, and eventually login passwords to email servers etc... ie: anything stored in gnome-keyring.

If this won't be the case, and the epiphany developers want to force everybody to stay on their own little island when it comes to passwords, then I couldn't care less about solving this bug or solving the issue of a usable password manager for the user.

Again, I think that gnome-keyring needs more work before it meets your privary expectations. 

> No, you propose to enable disclosure of keyring item's existence (and their
> 'non-secret' attributes?) to other applications which isn't how it works now.

The prompt reveals the existence. This is how it works now, anywhere from screenshots (the network URI is in the prompt) to atk accessibility screen reading. 

So really the malicious applications have access, but legitimate programs are barred. And the end result is that the user's experience is less than optimal.

In the interest of finding a solution we can all live with, I've modified gnome-keyring so it now has better support for what you're trying to do:

http://bugzilla.gnome.org/show_bug.cgi?id=356670

The patch adds support for gnome-keyring items that are specific to one application and only that application. 

I hope this does the trick :)

My goal is to find a secure way in which the passwords on the system can be managed by a password manager without incurring the nasty steaming pile of 50 or so prompts dumped on the user at the same time. 

Created attachment 75479 [details] [review]
Implementation of functionality

Implementation of the described functionality. This adds a new set of methods: gnome_keyring_item_get_info_full() and gnome_keyring_item_get_info_full_sync() which allow you to control which parts of the information (ie: with or without secret) you want to retrieve. 

Prompts on the daemon side are only shown when accessing secrets or modifying/deleting information.

To test:

# Access keyring without secret
$ ./test-keyring b default 1 type: 1

# Access keyring with secrets 
./test-keyring i default 1

This does not include code from bug #356670. However when committing I'll probably need to commit the two patches together (and merge them appropriately, since they touch some of the same areas of code).

This has been committed to HEAD.

2006-10-31  Nate Nielsen  <nielsen@memberwebs.com>

    * gnome-keyring-daemon.c (request_allowed_for_app, access_request_from_item, 
    access_request_from_item_with_secret, op_get_item_info_collect, op_get_item_info_execute,
    op_get_item_acl_or_attributes_collect, schedule_ask):
    * gnome-keyring-daemon.h:
    * gnome-keyring-proto.c (gnome_keyring_proto_encode_op_string_int_int, 
    gnome_keyring_proto_decode_get_item_info):
    * gnome-keyring-proto.h:
    * gnome-keyring.c (gnome_keyring_item_get_info_full, gnome_keyring_item_get_info_full_sync): 
    * gnome-keyring.h:
    * test.c: Adds ability to access meta-data without accessing secret itself.
    This does not incur the ACL prompt. See bug #356298