From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6) Gecko/20040510 Epiphany/1.2.4 Description of problem: I am in the process of writting a PAM module that executes gnome-keyring-daemon and unlocks a user's default keyring using their system password. The benefit is that the user finds his keyring unlocked once he has logged in. This makes the use of gnome-keyring more transparent. An early version of pam_keyring is available at: http://www.flyn.org/projects/pam_keyring/index.html At this point, pam_keyring is not ready for production systems. However, I would like solicit comments on the concept behind it. Here are some notes about pam_keyring 0.0.1 currently: 1. I am working on an SELinux policy for pam_keyring (see pam_keyring_macros.te). In order to do this right I will have to make some changes to some other policies. At this point, ask SELinux to not enforce its policies if you want to experiment with pam_keyring. 2. Currently, gnome-session tries to start gnome-keyring-daemon. This does not make sense if pam_keyring has already done so. Make the following change to gnome-session in order to fix this (I plan on submitting a patch soon): - gsm_keyring_daemon_start (); + if (getenv("GNOME_KEYRING_SOCKET") == NULL) + gsm_keyring_daemon_start (); 3. Although I have read that calling gnome_keyring_unlock with NULL as the first argument should unlock the default keyring, this does not seem to be the case. Replace "test" in pam_keyring.c with the name of your default keyring. 4. Ensure the password that unlocks your default keyring is the same as your system password. Version-Release number of selected component (if applicable): gnome-keyring-0.2.0-1 How reproducible: Always Steps to Reproduce: Note that you have to enter a password to log in and then enter another password to unlock your GNOME keyring. Additional info:
I fixed cvs HEAD to unlock the default keyring if you pass NULL (that can't hurt). You can also use the gnome_keyring_get_default_keyring() function. What OSX does is: By default, each Mac OS X login account has one keychain (for a new login on Mac OS X v10.3, this keychain is named login.keychain); however, a user or application can create as many keychains as desired. The login keychain is automatically unlocked during login if it has the same password as the userâs login account password. When first created, the login keychain is also the default keychain. The default keychain is used to store newly-created keychain items unless a different keychain is specified in the function call; certain other Keychain Services functions also use the default keychain when no other keychain is specified. The user can use the Keychain Access utility to designate another keychain as the default; however, the login keychain doesnât change. Maybe something like that would be good, because you might not always want to automatically unlock all your passwords. Another thing i worry about is daemon shutdown. gnome-session currently shuts down the daemon on logout, because we don't want the process running when the user logs out (thats a security problem). Can this be solved somehow?
Killing the daemon is handled by implementing a PAM close session function, so this is not a problem. A note on pam_keyring 0.0.1 that I forgot to mention: currently, my UID/GID is hard coded into pam_keyring.c. If you want to try this unstable version then you will need to do a s/500/<your UID>/g. Obviously, UIDs will be automatically looked up given the user's login name soon. My intention with 0.0.1 is to get some feedback early in the development process.
I'm really not the right version to look at pam stuff, if you want better feedback, try mailing privately to nalin. He's our pam guy, and he's interested in gnome-keyring too.
I think we should do this for FC5. Nalin, what are your thoughts on this?
I don't think it's a good idea. Or rather, that it may be a good idea, but that the implementation might end up making things more inconsistent for users than the current, separated state. If the keyring is password-protected, and you want to unlock it with the user's login password, you've implicitly made at least two assumptions: 1) if the user changes her password, you're in a position to change the password you've used to lock the keyring If the user's on a network, and changes her password through any means you don't control (think about the "go to this web page to reset your password" case), the one-password functionality "breaks" unexpectedly. 2) the user uses a password to log in If the user is using a smart card, one-time passwords, or is logging in remotely using strong authentication such as a public key or a GSSAPI mechanism, it just plain doesn't work because no password is exchanged. The problem being that we want to increase the use of these technologies.
Okay, that's enough resistance for me.
While I agree with the considerations in comment #5, I DO believe that this is an important bug and should be re-opened. How about a "Attempt to unlock keychain with login password" option? By closing this bug, you are ignoring the current usability problem... Case: User is using a notebook, completely mobile, and 95% of the time uses wireless access with it (this is my situation, and I believe that you will find MANY others in the same situation). User adds /usr/sbin/nm-applet to the Gnome startup preferences so that nm-applet start at each login. Result: When user enters login and password for GDM, he is immediately accosted for anoter login/password (which may be the same) to start nm-applet. By the way, THIS HAPPENS EVEN IF THERE IS A HARD WIRED CONNECTION AVAILABLE. I believe that this is an unacceptable outcome for this case. Just my $0.02, and I'll work around it in the end, but this is just the kind of behavior that causes resistance to using Linux on the desktop.
I completely agree with Bernard Johnson. See the following thread, exctly raising this problem for network-manager. http://mail.gnome.org/archives/networkmanager-list/2005-October/msg00164.html Please do not understimate this point. It is quite annoying to have to type 3 passwds (login, ssh-agent, gnome-keyring) just to connect on a laptop. Ideally I would like just to type one, by default. ---Beppe---
Maybe it would be easier and better to try to use the ssh passphrase from gnome-ssh-askpass. Currently this application (or ssh below) is already intelligent enough to use my one time given passphrase to unlock both my ssh1 and ssh2 keys - or, if the passphrases are different, it asks me again for the second. Why not extend such an application to ask for passphrases (but first try to reuse them) for things like NM? This could prove to be easier to handle than plugging into the system login dialog.
Or the other way round, delegate to gnome-keyring to handle also ssh-agent work. Or as a minimial solution, allow the user to define key-rings without passwd (even the default one?), or for which passwd is reuired only for modification and clear-text display of the key. So for instance I would create a keyring for NetworkManager ono my laptop so that it asks me the keyring passwd only if I want to change the WEP key of some network, or read it in clear text.
As this bug is still assigned to me (though it shouldn't, really, but that is another matter) I'm going to reopen it, because, as noted in the comments above this is a real usability issue: applications need a secure way of storing secrets. It just so happens that the GNOME way of doing this is by using gnome-keyring which is one API of many that performs this service (other API's that come to mind are the KDE wallet and the NSS from Mozilla). My view is that this largely a distribution headache we need to solve in Fedora: we need to be able to unlock multiple keyrings (containing secrets) upon an authorized login.
Change the Summary to adequately reflect the problem at hand.
Looks like this is getting some momentum upstream: NetworkManager Work Items - http://live.gnome.org/NetworkManagerToDo Bug 331529 â [enh] system-wide config to stop annoying keyring-on-login dialog - http://bugzilla.gnome.org/show_bug.cgi?id=331529 Bug 312877 â GDM login should open the keyring - http://bugzilla.gnome.org/show_bug.cgi?id=312877 Bug 326925 â need for a keyring that is unlocked than logging in - http://bugzilla.gnome.org/show_bug.cgi?id=326925
I have launched my initial release of pam_keyring, since taking over the project from Mike. It can unlock the default, or a specified keyring using the login password. The limitation to this is if you specified a different password for your default keyring you are kind of hosed because gnome-keyring doesn't support changing passwords yet ( FYI, I am working on a patch that should be submitted soon that will take care of this limitation ). Other than that all other bugs and limitations have been cleaned up I think. Feedback is of course appreciated. http://www.hekanetworks.com/pam_keyring/
Jon- Can you post the source rpm as well?
I personally think this looks good; so in the event the login password is changed so it's different from the gnome-keyring password, how about popping up a dialog that instructing the user to change his gnome-keyring password to the new password? Obviously this requires the old password so great care must be taken not to confuse the user... Of course, the real fix involves Single Sign On (btw, Nalin, how is that going?) but I guess this works in the interim; personally I'm sick and tired of having to unlock gnome-keyring every time I want to use VPN or my encrypted removable disks... Alex, Nalin, what do you think?
I generally like the idea. I agree that having to sync the keyring password with the user password is a weakness, but that doesn't imho mean we shouldn't do this. However, I really don't know much about pam and our work on single sign-on which this clearly is a part of, so I'm not the best person to ask. (Also, I'm busy with other stuff at the moment.)
Sorry about the delays guys. I forgot to add myself to the CC list of this bug, taken care of now. I have thought about both these situations and here is the rundown of my thoughts. Feedback is definitely welecomed. Change of password on Login. This was originally implemented in Mike's gnome-keyring-tool. I removed it because this has to be written into gnome-keyring with the api's for client usage. I have started writing this, but work has pulled me away from it temporarily. I will get it done soon I swear. Once that patch is implemented I can easily add this functionality back into pam-keyring-tool and the pam module and we are good. Passwords out of sync. If the above is done correctly then this shouldn't happen very much. If it does I am thinking this should be a boolean that is stored in the keyring that gnome-keyring-ask should pick up on. This gives you a different dialog something like, "this password is set to be unlocked on login, however the passwords differ. Please unlock this keyring with your old password and then set it's current password to use the one you logged in with." That is a quick rough dialogue, but I am sure you get the idea. I didn't know anything about pam when I started this either, all my experience was researching the existing pam modules and trying to get everything to fit together. I think I have crossed all my t's and dotted my i's. I am hoping for feedback from the pam list to really cement the fact I have done a decent job. I just knew this was a necessity for this design to work. This is only my first revision to get stuff to work correctly, get community support, and give the technology a good baseline. Ultimately I see the proper solution to be a special "login" keyring that is unlocked with and kept in sync with the system authentication password and then contains all the keyrings and associated passwords that a user can select to be unlocked on login. We then add the gui changes to gnome-keyring-manager and gnome-keyring-ask to have checkboxes for the user to select the "Unlock on login" box and the keyring-daemon automagically adds that keyring and necessary password to an encrypted keyring stored on the filesystem that can be read on login once the user has authenticated. This allows us to then have a NetworkManager, or Evolution, or Firefox keyring with different passwords, but not needing to keep unlocking or keeping track of them all. Just my thoughts. I think I have nailed down a bunch of the use cases, but I might be wrong, or not in sync with what the community needs.
I also forgot to add. I haven't built a source rpm, but can definitely do so if you definitely want one. In the contrib subdirectory of the tarball there is the spec file I used to build the rpm.
Added the source rpm to the site. http://www.hekanetworks.com/opensource/pam_keyring/pam_keyring-0.0.6-1.src.rpm
With the recent round of updates on Core 5 updates-testing, pam_keyring stopped working. I have fixed all known issues and updated the rpm's and tarballs. Please go to http://www.hekanetworks.com/pam_keyring/ for the new versions.
I just submitted a pam_keyring 0.0.7 package to Fedora Extras. Please see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187846
I think that we are just a few steps away from having a fully implemented pam module. Support for changing passwords was committed to gnome-keyring cvs today. I have a patch pending for password changing using gnome-keyring-manager. I will now get pam_keyring implemented to properly handle system password changes via passwd. That will give us a good solution for phase one. I will try and get that functionality implemented by the end of the weekend.
The pam_keyring module is now available in Fedora Extras' Rawhide tree.
Closing since pam-keyring is in fedora extras.