Re: cleaning up keyrings
On Wed, 2007-08-29 at 17:04 -0400, Havoc Pennington wrote: Hi, I wrote down the schemas for the current information stored by various apps. Here those are, essentially 5 kinds of object: Firefox/Epiphany/etc. Browser Web Site Login Domain (exact domain:port we logged in to) Please use another name, like host or something. Domain is so overloaded in the keyring domain (like windows domains, etc). GNOME Keyring Schema for File Shares (NETWORK_PASSWORD) Username Hostname Port Windows Domain Protocol (http, sftp, etc.) Object (i.e. random metadata string depending on type) Password (secret) There is also authtype for dav. Observations: 1) stuffing the other four into the gnome-keyring NETWORK_PASSWORD type is just wrong. NETWORK_PASSWORD makes no sense except for file shares. I think the Gossip patch trying to use it is wrong and the NetworkManager usage of it is wrong. They should use GENERIC_SECRET and have their own sensible field names. (By using NETWORK_PASSWORD, people are doing the equivalent of picking an existing, unrelated database table for their new data, and if they have an integer they pick some random column in the existing table that happens to be an integer, and put their integer in there... even if it meant something totally different before) Agreed. 2) There's a confusing thing about gnome-keyring, which is that it stores metadata like account name, but *it stores one item per secret, not one per account or whatever* - i.e. the metadata is just a way to look up the secret. gnome-keyring can be abused to store the metadata, but that isn't really the point of it. Really gnome-keyring is only intended to be the canonical store for the password, and you'd have some other storage for the account details. Yeah, it really is a password/secret store. Not a general application database. c) use gnome-keyring only for the *secrets*. i.e. say you query the IM accounts API, you would *separately* query gnome-keyring for the IM password (if you needed it). We still need docs for gnome-keyring that simply list the field names you can use to look up each secret. I agree. There is another possible usecase for gnome-keyring too. Take the firefox remember-input-fields hack. Instead of storing that in clear-text or hacking it into gnome-keyring directly (which might not fit well), just generate a random key and store that in the keyring, then when you save the input-fields, encode it with the key (perhaps just using xor or something simple). This is an easy way to make things like firefox more secure, while not forcing it to totally restructure the way it stores stuff. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: Hi, I guess my simpler API suggestion amounts to the same API currently used for network password, but with varargs for the properties so it can be used for any set of lookup properties So, I could have just said that I guess, sorry for the longer mail. The varargs are more convenient even for network password I think, because functions with tons of args are a pain to use - you have to keep carefully checking back to the header to be sure you have the right args in the right order. Especially when a bunch of them are NULL. We can add something like this for 2.22. Sadly the protocol between the daemon and library has been abused by binding authors [1], but I don't think any of these changes would need to affect the protocol. Cheers, Stef Walter [1] http://anonsvn.mono-project.com/viewcvs/trunk/gnome-keyring-sharp/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 18:23 -0400, Havoc Pennington wrote: Hi, Thanks for the bug links, those are helpful. Here are some questions I have about conventions for storing stuff in the keyring, which would be relevant to the Gossip bug (and future similar bug against Pidgin, etc.) - when do you use default/NULL vs. session keyring? (I think I've asked this before, but I forget) I see stef replied to this. Basically, session means don't save this to disk. - the Gossip patch sets user=havoc.pennington and server=gmail.com for my account, but why does it set server and not domain, and when would something set domain? Is domain intended for web passwords only? - what is the object field in gnome-keyring supposed to be for? NetworkManager vpn stuff sets it to password and group_password, the Gossip patch doesn't use it - Gossip patch sets protocol field to jabber, NetworkManager to org.freedesktop.NetworkManager.vpnc, ... ? when is this field used and what's its intended content? First of all you have to realize that gnome-keyring is very free-form in its objects. What you can do is map a set of key-value pairs (where values are ints or strings) to a secret. And, when you query you query for a secret you do so by passing a set of key-value pairs which will return a list of matching secrets, ordered so that the most specific comes first (i.e. has more keys set). So, for instance, you could save with just the keys type, user, server. And then query only on type and server, which will give you all the users + secrets stored for that server. So, back to the specific fields you're talking about above. They are used by the helper function like gnome_keyring_set_network_password. All these do is make it easier to handle typical network passwords. You don't have to use these specific fields, or you could set them using the lower level calls, its just a utulity functions. That said, here is what the fields are used for in gnome-vfs: user: the username domain: Windows domains for the user (smb) server: server hostname or ip number (as string) port: the tcp port on the server object: protocol-specific object reference: smb: the share name http: the authentication real sftp: ssh key name (for saving passphrases) protocol: http/ftp/sftp/smb authtype: for htp: basic or proxy, for sftp: password or publickey The protocol field is basically used to define what type of secret this is, so that when you add that as a filter you don't find other types of secrets. I'd recommend to have this for all secrets. The rest of the keys can be used (or not) in a per-protocol specific way that makes sense for that protocol. - I would think in Gossip or Pidgin you can create two accounts with the same username/password (true? or do they stop you?) - how would that be handled? I'm not sure what you mean by this. Two accounts on different types of IM systems? That would be handled by specifying more details than just the user/password (like protocol, etc). Ideally I think we'd allow Gossip and Pidgin to ask something like give me all XMPP accounts on the keyring, I guess that would use the protocol field? Would the results be sane if Gossip or Pidgin merged this resulting list of accounts with their own app-specific list of accounts? How should that merge be done? What if you delete an account in the app's account manager screen? Its certainly possible to use gnome_keyring_find_items (or the helper gnome_keyring_find_network_password) specifying only protocol=xmpp, which will give you all the items where you can read both the username and the other details and the password. This is how a http authentication works in gnome-vfs. We only feed gnome-keyring protocol=http, the server, port, authtype and the object (the auth realm). This gives us a list (typically of lenght 1) where we can read the username, as well as the secret password. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On 8/28/07, David Zeuthen [EMAIL PROTECTED] wrote: On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote: - fix Firefox to use the keyring, or at least let apps query Firefox password manager storage - have some mechanism for smart deductions, like I can guess you have an XMPP account that matches your google.com username/password - maybe this just has to be in the apps, not sure One important thing about the gnome-keyring prompts is that they display information the user should be able to trust / understand. Things like that App X is trying to use the key stored by App Y. [1] AFAIK, to do this in a secure way, the prompts stem from a separate process [2] and the code looks at the callers process id to determine what application (on Linux via /proc/pid/exe) is making the requests and then uses that name in prompts like these http://people.freedesktop.org/~david/gnome-keyring-allow-deny.png (actually this instance of the dialog, btw, looks pretty hostile to end users. Maybe I'm just not using gnome-keyring correctly from gnome-mount to save the LUKS pass phrase in the keyring. Shrug.) The key here is that information you show in these prompts absolutely needs to be trusted; you just cannot let the caller of the keyring API pass in random junk; you cannot trust them. So I wonder how this would work with Firefox. Ideally you want to display The gmail.com website (and ideally also display some kind of icon whether the website in question is signed by a trusted third-party.) instead of The application Firefox As I see it, to do this the keyring prompts would need to trust the Firefox process to get this information or you run the risk of displaying wrong information to the user... Sounds like a pretty hard problem to me. Just some thoughts / ramble. Hope it's useful. David [1] : In fact I'm skeptical that most users will do more than just click through these prompts... if we didn't care about protecting secrets on a per-application basis we would be just as well off with encrypted homedir and just store secrets in plaintext. And then we wouldn't need a keyring API at all. [2] : Which is good as it means it's possible to 1) Restrict access to the keyring database to a specific security context etc. that only the gnome-keyring programs run in; and 2) In the future use of XACE to paint different window decorations to make the dialog look more trusted (doubtful approach to security but I thought I'd mention it anyway); and 3) Show the dialogs it on a different X server (e.g. the gdm greeter) possibly using a Secure Attention Key (ctrl+alt+del) to get there. I'm probably missing lots of understanding of how this system works, but I have a few questions I'd like your feedback on for initially reducing the amount of password prompting. I'll start with this one and see where it goes before I ask more. Can an application that stores a secret be able to retrieve that same secret without unlocking the keyring? I never really understand why NetworkManager, the one who put certain secrets into my keyring needs to ask my permission to get those secrets back. Sure those secrets are my passwords, but I already gave them to NM once, why does it need to ask to get them again? If it wasn't a good idea to give those passwords to NM the first time, it's too late because it already has them. If Firefox, for some reason, wanted access to the secrets that NetworkManager stored I think that has cause for some alarm. The warning for this situation is a little easier, because it's less often and probably shouldn't happen unless something is really wrong. Even though the keyring is locked, it seems like the application that set the secret should be able to retrieve it. I don't know how you want to make sure it's the same calling application, there might be some tricks in that. But this would reduce the number of login / access the keyring dialogs. Perhaps my vision of the keyring is more of a secure little area where applications can save data that's reliable and encrypted and I have the master password to; however if an application wants to save some random secret bits in the keyring that only it will retrieve later I find it pretty harmless. Is that a false assumption? -- One key to having better security is to not cry wolf to our user all the time. In reality, even without crying wolf they are going to click through whatever dialogs we bring up so we might as well work with the mindset in our designs to not bring up the dialogs at all. They'll likely be some exceptions where we feel a dialog is necessary, however each dialog really means we've failed at being secure and passed the buck on to our users. ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Bryan Clark wrote: Can an application that stores a secret be able to retrieve that same secret without unlocking the keyring? Yes for sure. I never really understand why NetworkManager, the one who put certain secrets into my keyring needs to ask my permission to get those secrets back. Sure those secrets are my passwords, but I already gave them to NM once, why does it need to ask to get them again? If it wasn't a good idea to give those passwords to NM the first time, it's too late because it already has them. Odd, it shouldn't do that. I've never seen it do the ACL prompt for the application that stored the secret. However with previous versions of GNOME (previous to 2.20) it did need to prompt for a passphrase once per session in order to unlock the keyring. This nonsense has now been solved: http://live.gnome.org/GnomeKeyring/Pam Even though the keyring is locked, it seems like the application that set the secret should be able to retrieve it. I don't know how you want to make sure it's the same calling application, there might be some tricks in that. But this would reduce the number of login / access the keyring dialogs. Yes, this is already the case. When a new secret is stored, an ACL is automatically added to that item for the application that stored it. If the originating application accesses that item, then no prompt should ever be issued. If you see a prompt in a certain case, then it's definitely a bug. One key to having better security is to not cry wolf to our user all the time. In reality, even without crying wolf they are going to click through whatever dialogs we bring up so we might as well work with the mindset in our designs to not bring up the dialogs at all. They'll likely be some exceptions where we feel a dialog is necessary, however each dialog really means we've failed at being secure and passed the buck on to our users. For sure. And the access prompts that occur when one application accesses another applications secrets (usually legitimately) are very dumb from the perspective of the user. This is a hard problem, as David pointed out. In fact our current 'prompting' solution only really works for C applications (with their own unique executable path), so I would call it fundamentally broken. http://bugzilla.gnome.org/show_bug.cgi?id=342144 Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
David Zeuthen wrote: http://people.freedesktop.org/~david/gnome-keyring-allow-deny.png (actually this instance of the dialog, btw, looks pretty hostile to end users. Maybe I'm just not using gnome-keyring correctly from gnome-mount to save the LUKS pass phrase in the keyring. Shrug.) I would suggest storing the secret with human readable text as the display name of the item. You can store HAL ids in the item attributes, and then use them to find the appropriate item later. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, Even though the keyring is locked, it seems like the application that set the secret should be able to retrieve it. I don't know how you want to make sure it's the same calling application, there might be some tricks in that. But this would reduce the number of login / access the keyring dialogs. So, at some point a password has to be asked for, because that password is used to unencrypt the data. In theory only one password should need to be asked for though, the password (or smart card PIN code) you type when you login. That's the whole single sign on dream, and what pam_gnomekeyring is trying to tackle. Perhaps my vision of the keyring is more of a secure little area where applications can save data that's reliable and encrypted and I have the master password to; however if an application wants to save some random secret bits in the keyring that only it will retrieve later I find it pretty harmless. Is that a false assumption? If the data is encrypted then the application won't be able to get to the data until it's unencrypted, which means asking for a password. Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. The Linux kernel key service can do this for session/user/user+session and other key types, and you can use SELinux labels on it. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/29/07, Alan Cox [EMAIL PROTECTED] wrote: Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. The Linux kernel key service can do this for session/user/user+session and other key types, and you can use SELinux labels on it. But the kernel keyring isn't persistent across reboots is it? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Wed, 29 Aug 2007 16:39:04 -0400 Ray Strode [EMAIL PROTECTED] wrote: Hi, On 8/29/07, Alan Cox [EMAIL PROTECTED] wrote: Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. The Linux kernel key service can do this for session/user/user+session and other key types, and you can use SELinux labels on it. But the kernel keyring isn't persistent across reboots is it? It provides a mechanism to manage the keys and to use SELinux labels on them to control access. If you want to save them across reboots then that would need user space involvement as well. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: I wrote down the schemas for the current information stored by various apps. Here those are, essentially 5 kinds of object: Firefox/Epiphany/etc. Browser Web Site Login Domain (exact domain:port we logged in to) Username Password Username Input Field Name Password Input Field Name Sadly an HTTP login is far more complex than just that. In basic and digest authentication 'realm' is sent from the server, which is really what defines which login to use. Also digest authentication has the concept of a 'domain', which is the URI prefixes with which a login should be automatically used. http://www.ietf.org/rfc/rfc2617.txt 1) stuffing the other four into the gnome-keyring NETWORK_PASSWORD type is just wrong. NETWORK_PASSWORD makes no sense except for file shares. I think the Gossip patch trying to use it is wrong and the NetworkManager usage of it is wrong. They should use GENERIC_SECRET and have their own sensible field names. (By using NETWORK_PASSWORD, people are doing the equivalent of picking an existing, unrelated database table for their new data, and if they have an integer they pick some random column in the existing table that happens to be an integer, and put their integer in there... even if it meant something totally different before) If we want we can make additional gnome keyring item types, but these would need to be fairly far well established groupings. It may be that we add an item type for IM accounts, another for email accounts, etc. I think one reason people are using the network password type is because there are gnome-keyring convenience APIs for using this type. 2) There's a confusing thing about gnome-keyring, which is that it stores metadata like account name, but *it stores one item per secret, not one per account or whatever* - i.e. the metadata is just a way to look up the secret. gnome-keyring can be abused to store the metadata, but that isn't really the point of it. Really gnome-keyring is only intended to be the canonical store for the password, and you'd have some other storage for the account details. Yes, the main limitation is that of one secret per item. If you wanted to use it for account data that would be possible with that limitation. The ACL infrastructure (where applications can specify something as for them only) might be handy when storing accounts. But perhaps account data has a better life elsewhere, like you noted. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi,
On 8/29/07, Stef Walter [EMAIL PROTECTED] wrote:
Sadly an HTTP login is far more complex than just that. In basic and
digest authentication 'realm' is sent from the server, which is really
what defines which login to use.
Also digest authentication has the concept of a 'domain', which is the
URI prefixes with which a login should be automatically used.
You're talking about http auth here, I'm talking about the feature
where Firefox fills out your login in the html page. (password
manager - see that mozilla wiki link I sent in the original post,
which describes the schema)
http auth can probably use the NETWORK_PASSWORD type as nautilus does for DAV.
If we want we can make additional gnome keyring item types, but these
would need to be fairly far well established groupings. It may be that
we add an item type for IM accounts, another for email accounts, etc.
I think one reason people are using the network password type is because
there are gnome-keyring convenience APIs for using this type.
It may also be due to total lack of any docs ;-)
I think maybe it would be better to do something like:
- have a super-convenient, simpler API for the normal app use case:
store, list, and delete
- split this API out to the top of the file with a big comment
USE THIS STUFF --
and then another after it:
IGNORE ALL THE REST OF THIS
;-)
- also have a comment/docs describing the property names to use for
some of the common schemas I just mentioned
Anyway, the point is do a convenience API that just makes it simple to
use the property names, and then rearrange the header and docs so you
just see the few things most apps care about and don't have to try to
dig through that huge gnome-keyring.h header. Most of the API is only
useful for a keyring manager and other obscure cases.
Yes, the main limitation is that of one secret per item. If you wanted
to use it for account data that would be possible with that limitation.
The ACL infrastructure (where applications can specify something as for
them only) might be handy when storing accounts.
But perhaps account data has a better life elsewhere, like you noted.
That's my opinion, if only because realistically apps are not going to
port to store their main list of accounts in gnome-keyring, and
there's no real benefit if they do anyway. I'd say keep it simple and
say gnome-keyring is just for secrets.
Here's a sketch of what I think a simpler API might be like:
enum {
KEEP_IN_MEMORY,
SAVE_TO_DISK
} StorageScope;
char *the_secret_data = top secret;
/* store a secret, so it can be looked up using the provided properties */
store_secret(SAVE_TO_DISK, the_secret_data, username:string, hp,
port:int, 80, server:string, example.com, NULL);
/* load all secrets matching the provided properties */
KeyringSecret **secrets = load_secrets(username:string, hp,
port:int, 80, server:string, example.com, NULL);
/* delete all secrets that match the provided properties */
delete_secrets(username:string, hp, port:int, 80,
server:string, example.com, NULL);
/* delete a specific secret */
delete_secret(secrets[0]);
char *my_secret = secret_get_secret(secrets[0]);
/* not even sure this is needed... should already be known to the app */
char *username = secret_get_string(secrets[0], username);
Concepts the app developer could avoid knowing to use this simpler API:
- KeyringResult
- KeyringItemType
- AttributeList
- KeyringFound
- default vs. session
- create/delete non-default keyrings
- item IDs
- ACLs
- special network password schema and related API/datatypes
those are all useful sometimes, but not needed in a convenience API.
Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, I guess my simpler API suggestion amounts to the same API currently used for network password, but with varargs for the properties so it can be used for any set of lookup properties So, I could have just said that I guess, sorry for the longer mail. The varargs are more convenient even for network password I think, because functions with tons of args are a pain to use - you have to keep carefully checking back to the header to be sure you have the right args in the right order. Especially when a bunch of them are NULL. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
- have some mechanism for smart deductions, like I can guess you have an XMPP account that matches your google.com username/password - maybe this just has to be in the apps, not sure This needs some care. There are evils that lurk on the web side of this. One big one is that if a central service provides a guessed login/password from another source to firefox, I can steal it using javascript into a hidden form which might be bad if I can trigger wrong guesses. For pure web use this problem doesn't normally arise as the URI gives a scope which makes sense, once you take guesses from outside you don't know enough to guess where to paste them. I just started thinking about this today, so let me know what's missing. One of the things you can use the TPM for in a treacherous computing system is simply as a poor quality smart card. And for that matter working with a proper smart card is similar. Being able to share my keyring simply by - USB - Bluetooth - Internet - Smart Card - TPM (where there is a common root key) including merging entries from multiple sources. PAM already lets me direct sensitive system authentication questions to a seperate trusted display (my phone) which I can't currently do for the other apps. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote: snip Anyway, I'm thinking about how to clean up the password-storage situation. Here is the current situation: - Pidgin just sticks passwords in plain text in app-specific XML files - Gossip does the same thing, plain text in XML files - Firefox has its whole own thing, though they have plans to use the Keychain on OS X they are not planning to use gnome-keyring according to possibly-outdated wiki page: http://wiki.mozilla.org/Firefox:Password_Manager As usual, Firefox' integration in the desktop stinks. That's why a number of us use Epiphany. FYI, that's what's missing to get Epiphany to use the gnome-keyring: https://bugzilla.mozilla.org/show_bug.cgi?id=265780 https://bugzilla.mozilla.org/show_bug.cgi?id=351427 from: http://bugzilla.gnome.org/show_bug.cgi?id=130336 Pidgin has the same disease as Firefox, wants to be everywhere, thus is integrated nowhere. OpenSUSE seems to have a patch to make use of the gnome-keyring though. I found it in: ftp://ftp5.gwdg.de/pub/opensuse/repositories/GNOME%3A/UNSTABLE/openSUSE_10.2/src/pidgin-2.1.0-2.3.src.rpm Gossip should really know better though: http://bugzilla.gnome.org/show_bug.cgi?id=343513 Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, Thanks for the bug links, those are helpful. Here are some questions I have about conventions for storing stuff in the keyring, which would be relevant to the Gossip bug (and future similar bug against Pidgin, etc.) - when do you use default/NULL vs. session keyring? (I think I've asked this before, but I forget) - the Gossip patch sets user=havoc.pennington and server=gmail.com for my account, but why does it set server and not domain, and when would something set domain? Is domain intended for web passwords only? - what is the object field in gnome-keyring supposed to be for? NetworkManager vpn stuff sets it to password and group_password, the Gossip patch doesn't use it - Gossip patch sets protocol field to jabber, NetworkManager to org.freedesktop.NetworkManager.vpnc, ... ? when is this field used and what's its intended content? - I would think in Gossip or Pidgin you can create two accounts with the same username/password (true? or do they stop you?) - how would that be handled? Ideally I think we'd allow Gossip and Pidgin to ask something like give me all XMPP accounts on the keyring, I guess that would use the protocol field? Would the results be sane if Gossip or Pidgin merged this resulting list of accounts with their own app-specific list of accounts? How should that merge be done? What if you delete an account in the app's account manager screen? A specific use-case is that if I've already logged in to Google in either Firefox or BigBoard, I think Gossip or Pidgin when first started up should default to knowing that same account info. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 22:56 +0100, Bastien Nocera wrote: Gossip should really know better though: http://bugzilla.gnome.org/show_bug.cgi?id=343513 FWIW, Gajim uses the keyring. Which is nice. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: I forgot to mention taking the encrypted keyring blob and sticking it on a server somewhere, but (I think) that's an independent issue from getting everything to use the same keyring and same keyring entries. Well there are obviously security issues to this. Perhaps there should be a way of having a single certain keyring (with a given name) stored online, and applications could choose whether or not to store passwords in that keyring. My reasoning is in part because, in the next cycle gnome-keyring is getting support for encryption keys (SSH, X509). If those were stored online, it would negate their value a good deal. If encryption keys were downloadable using a password, then why use an encryption key for things like SSH at all? Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Alan Cox wrote: I just started thinking about this today, so let me know what's missing. One of the things you can use the TPM for in a treacherous computing system is simply as a poor quality smart card. And for that matter working with a proper smart card is similar. Being able to share my keyring simply by - USB - Bluetooth - Internet - Smart Card - TPM (where there is a common root key) including merging entries from multiple sources. PAM already lets me direct sensitive system authentication questions to a seperate trusted display (my phone) which I can't currently do for the other apps. You can do this via USB today with gnome-keyring. There's currently not much UI for it (I'd like to implement the UI properly), but it should work: http://live.gnome.org/GnomeKeyring/Removable If properly thought out, it seems Internet storage of a keyring could work in a similar way. More on this later... Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: Anyway, I'm thinking about how to clean up the password-storage situation. Here is the current situation: - Pidgin just sticks passwords in plain text in app-specific XML files - Gossip does the same thing, plain text in XML files - Firefox has its whole own thing, though they have plans to use the Keychain on OS X they are not planning to use gnome-keyring according to possibly-outdated wiki page: http://wiki.mozilla.org/Firefox:Password_Manager I believe the epiphany guys have been working on this, at some point: http://bugzilla.gnome.org/show_bug.cgi?id=130336 - BigBoard puts things in gnome-keyring Looking in gnome-keyring-manager, there's barely anything in there. Yeah, one big problem with gnome-keyring was the problem of having to enter your password twice, which really bugged users. I hope that with the PAM integration in 2.20, this major excuse for not using gnome-keyring will be no more. Evolution, for example, has gnome-keyring support but is rarely compiled with it due to the above. Looking at gnome-keyring-manager does hint at one problem, though; gnome-keyring is too policy free and free-form. It provides a shared password facility, but no real guideline for _how_ to store the passwords or how to find the password for a particular thing or particular site. Yes a spec does seem necessary to help coordinate what is stored in each of the individual attributes. We ran into this problem with seahorse and gnome-gpg, each of which wanted to store passwords for PGP keys in the keyring. We probably also want to add one or more keyring item types, eg: for web form data. The current list of item types: GNOME_KEYRING_ITEM_GENERIC_SECRET GNOME_KEYRING_ITEM_NETWORK_PASSWORD GNOME_KEYRING_ITEM_NOTE - have some mechanism for smart deductions, like I can guess you have an XMPP account that matches your google.com username/password - maybe this just has to be in the apps, not sure Along with what Alan said, pushing this too far down the stack opens up many possibilities for password retrieval attacks, like the recent spate of attacks that exploited this in Firefox and Safari. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi Havoc, Cleaning up and making more apps use the keyring is definitely a worthwhile effort in my mind. On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote: - fix Firefox to use the keyring, or at least let apps query Firefox password manager storage - have some mechanism for smart deductions, like I can guess you have an XMPP account that matches your google.com username/password - maybe this just has to be in the apps, not sure One important thing about the gnome-keyring prompts is that they display information the user should be able to trust / understand. Things like that App X is trying to use the key stored by App Y. [1] AFAIK, to do this in a secure way, the prompts stem from a separate process [2] and the code looks at the callers process id to determine what application (on Linux via /proc/pid/exe) is making the requests and then uses that name in prompts like these http://people.freedesktop.org/~david/gnome-keyring-allow-deny.png (actually this instance of the dialog, btw, looks pretty hostile to end users. Maybe I'm just not using gnome-keyring correctly from gnome-mount to save the LUKS pass phrase in the keyring. Shrug.) The key here is that information you show in these prompts absolutely needs to be trusted; you just cannot let the caller of the keyring API pass in random junk; you cannot trust them. So I wonder how this would work with Firefox. Ideally you want to display The gmail.com website (and ideally also display some kind of icon whether the website in question is signed by a trusted third-party.) instead of The application Firefox As I see it, to do this the keyring prompts would need to trust the Firefox process to get this information or you run the risk of displaying wrong information to the user... Sounds like a pretty hard problem to me. Just some thoughts / ramble. Hope it's useful. David [1] : In fact I'm skeptical that most users will do more than just click through these prompts... if we didn't care about protecting secrets on a per-application basis we would be just as well off with encrypted homedir and just store secrets in plaintext. And then we wouldn't need a keyring API at all. [2] : Which is good as it means it's possible to 1) Restrict access to the keyring database to a specific security context etc. that only the gnome-keyring programs run in; and 2) In the future use of XACE to paint different window decorations to make the dialog look more trusted (doubtful approach to security but I thought I'd mention it anyway); and 3) Show the dialogs it on a different X server (e.g. the gdm greeter) possibly using a Secure Attention Key (ctrl+alt+del) to get there. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 18:23 -0400, Havoc Pennington wrote: Hi, Thanks for the bug links, those are helpful. Here are some questions I have about conventions for storing stuff in the keyring, which would be relevant to the Gossip bug (and future similar bug against Pidgin, etc.) snip I'm not sure anyone's really thought of the conventions behind using each field for something specific. You'd need to ask Alex, he wrote it after all :) Ideally I think we'd allow Gossip and Pidgin to ask something like give me all XMPP accounts on the keyring, I guess that would use the protocol field? Would the results be sane if Gossip or Pidgin merged this resulting list of accounts with their own app-specific list of accounts? How should that merge be done? What if you delete an account in the app's account manager screen? Apps would need to agree on what/how to store it. I guess that right now, it's good enough if the app that inserted the details can read it back. A specific use-case is that if I've already logged in to Google in either Firefox or BigBoard, I think Gossip or Pidgin when first started up should default to knowing that same account info. How? I personally log in to google with my personal mail address, don't have any GMail account, and have a @googlemail.com Jabber address. I'm not sure how apps are supposed to link all those (and they'd need access to the cookies, another thing to share, to be able to screenscrape). -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: - when do you use default/NULL vs. session keyring? (I think I've asked this before, but I forget) Use NULL (which automatically maps to the default keyring) when you don't care what keyring a password is stored in, but you want it stored for good. In many cases this will be the 'login' keyring which is automatically unlocked when the user logs into their session. Use 'session' (this should really be a #define in gnome-keyring.h) when something should only be stored for the session. gnome-keyring just got its documentation this cycle (library.gnome.org doesn't seem to have it yet). - the Gossip patch sets user=havoc.pennington and server=gmail.com for my account, but why does it set server and not domain, and when would something set domain? Is domain intended for web passwords only? Domain, as far as I know was intended for windows network shares. - what is the object field in gnome-keyring supposed to be for? NetworkManager vpn stuff sets it to password and group_password, the Gossip patch doesn't use it This was originally used for the share name in windows network shares, and I've seen it used for for 'paths' underneath the main hostname. Ideally I think we'd allow Gossip and Pidgin to ask something like give me all XMPP accounts on the keyring, I guess that would use the protocol field? Would the results be sane if Gossip or Pidgin merged this resulting list of accounts with their own app-specific list of accounts? How should that merge be done? What if you delete an account in the app's account manager screen? So what you're really talking about is storing the concept of an 'account' with all related information in gnome-keyring. So far the focus has been on passwords and secrets. This is certainly possible, but like you said needs a solid spec to get anywhere. The way current applications store information in the keyrings just isn't structured enough. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, Stef Walter [EMAIL PROTECTED] wrote: Havoc Pennington wrote: I forgot to mention taking the encrypted keyring blob and sticking it on a server somewhere, but (I think) that's an independent issue from getting everything to use the same keyring and same keyring entries. Well there are obviously security issues to this. Perhaps there should be a way of having a single certain keyring (with a given name) stored online, and applications could choose whether or not to store passwords in that keyring. Right, I think it would be an option of some kind. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, Stef Walter [EMAIL PROTECTED] wrote: - have some mechanism for smart deductions, like I can guess you have an XMPP account that matches your google.com username/password - maybe this just has to be in the apps, not sure Along with what Alan said, pushing this too far down the stack opens up many possibilities for password retrieval attacks, like the recent spate of attacks that exploited this in Firefox and Safari. I think you guys may understand this backward from what I meant. I am saying if you logged in to google (or Flickr, or whatever) in the browser, then your desktop apps could get at that login info. I'm not saying that the browser could get stuff from the desktop - JavaScript remains sandboxed as usual. (Though as long as somethingis tagged with a domain, and the domain is exact-matched, that might be fine too I would think. But of course it would have to be very carefully defined what the domain field means and who sets it.) The functionality I'm after is the same thing we already have for online.gnome.org, where if you are logged in to the web site, then the desktop can use the same cookie to sign on to the XMPP server. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, Bastien Nocera [EMAIL PROTECTED] wrote: I'm not sure anyone's really thought of the conventions behind using each field for something specific. You'd need to ask Alex, he wrote it after all :) I am hoping he'll read the thread ;-) Ideally I think we'd allow Gossip and Pidgin to ask something like give me all XMPP accounts on the keyring, I guess that would use the protocol field? Would the results be sane if Gossip or Pidgin merged this resulting list of accounts with their own app-specific list of accounts? How should that merge be done? What if you delete an account in the app's account manager screen? Apps would need to agree on what/how to store it. I guess that right now, it's good enough if the app that inserted the details can read it back. That's the point though, I don't think it's really a good situation; if I create a guest account right now, I have to log in to Google three times to get it all going, and that's just one example. Without sharing between apps gnome-keyring doesn't do a whole lot other than throw up allow-or-deny dialogs like Vista. ;-) The ideal is that one local login and one online.gnome.org login is all you need, then your keyring is downloaded and has all other logins. (yes, it will be optional, to head off the inevitable followup) A specific use-case is that if I've already logged in to Google in either Firefox or BigBoard, I think Gossip or Pidgin when first started up should default to knowing that same account info. How? I personally log in to google with my personal mail address, don't have any GMail account, and have a @googlemail.com Jabber address. I'm not sure how apps are supposed to link all those (and they'd need access to the cookies, another thing to share, to be able to screenscrape). It won't work if you have a setup like that, or would require more effort to make work. But for example it's easy to make work for my Google setup which is all @gmail.com This isn't something that has to work every time or in every corner case to be useful. It's just something that's nice to do whenever we can. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
the one thing that drives me nuts about gmail is that it doesn't default to reply all... On 8/28/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, On 8/28/07, Stef Walter [EMAIL PROTECTED] wrote: So what you're really talking about is storing the concept of an 'account' with all related information in gnome-keyring. Well, maybe. I was just thinking about that a bit and it seems probably too ambitious. I'd be happy to start if apps could just ask for a list of username/password pairs by category, like XMPP, Google, Flickr, or whatever. I think that's enough for apps to do something reasonably nice. Not sure though. So far the focus has been on passwords and secrets. This is certainly possible, but like you said needs a solid spec to get anywhere. The way current applications store information in the keyrings just isn't structured enough. Exactly, yep. I can write some simple spec up, but first I want to understand all the current thinking (so far it sounds like there's a pretty blank slate for spec'ing this out) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 18:48 -0400, Havoc Pennington wrote: The functionality I'm after is the same thing we already have for online.gnome.org, where if you are logged in to the web site, then the desktop can use the same cookie to sign on to the XMPP server. If cookies are all you want, then all we need is just to make (all) the browser and (all) the apps use the same underlying HTTP library, right? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, David Zeuthen [EMAIL PROTECTED] wrote: One important thing about the gnome-keyring prompts is that they display information the user should be able to trust / understand. Things like that App X is trying to use the key stored by App Y. [1] Yeah. I'm not sure these dialogs make sense, but for now I'm ignoring them and just worrying about how all apps can share the same login knowledge (you'd still have to allow/deny each app). For why I don't think they make sense, it's pretty much the same issue as https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00309.html Either you have a secure setup or you don't, dialogs are just a really annoying-to-the-user way of writing if (TRUE) and don't affect the security materially. A better approach, for example, would be to have selinux or signatures or something such that apps that come with the OS are automatically trusted and the dialog or other obscure procedure only arises for third-party apps. Then people don't get as used to just clicking yes all the time and _might_ slow down for the dialog when it really matters. But, it's a somewhat separate topic from what I was wanting to mess with right away. [1] : In fact I'm skeptical that most users will do more than just click through these prompts... if we didn't care about protecting secrets on a per-application basis we would be just as well off with encrypted homedir and just store secrets in plaintext. And then we wouldn't need a keyring API at all. I think the keyring API is most useful for sharing the login info between apps, and potentially storing the login info on a server (or a USB key, or whatever) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
resend to list... On 8/28/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, On 8/28/07, David Zeuthen [EMAIL PROTECTED] wrote: On Tue, 2007-08-28 at 18:48 -0400, Havoc Pennington wrote: The functionality I'm after is the same thing we already have for online.gnome.org, where if you are logged in to the web site, then the desktop can use the same cookie to sign on to the XMPP server. If cookies are all you want, then all we need is just to make (all) the browser and (all) the apps use the same underlying HTTP library, right? I didn't mean cookies literally, I meant the thing where you log in to one conceptual server only one time per desktop session But yes, we need the shared HTTP lib too. ;-) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Exactly, yep. I can write some simple spec up, but first I want to understand all the current thinking (so far it sounds like there's a pretty blank slate for spec'ing this out) You might want to have a chat with Dave Howells at Red Hat as well. Dave did the Linux kernel side key management which handles keys on a thread through to user and group level. Documentation/key* in the kernel. This is used to manage keys needed for things like file systems but can be used for other stuff too. It also supports callbacks so the kernel can ask user space about keys. Currently this is used by the ecryptfs and AFS/RXRPC file/net system layers, and also by the MMC/SD layer for managing passwords to encrypted cards. It'll probably soon get used by libata to manage passworded disks (and thus passworded compact flash) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 19:08 -0400, Havoc Pennington wrote: A better approach, for example, would be to have selinux or signatures or something such that apps that come with the OS are automatically trusted and the dialog or other obscure procedure only arises for third-party apps. Then people don't get as used to just clicking yes all the time and _might_ slow down for the dialog when it really matters. Certainly. Maybe add to your spec that there needs to be an easy way for OS vendors / site / system admins to maintain a whitelist of apps that are always allowed to access a certain types of keys without having to nag the user. Means you need a grouping/type concept though. (And FWIW I think path-based security is more than sufficient here.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
