GNOME Bugzilla – Bug 386866
gnome-keyring should support blank passwords
Last modified: 2007-12-19 15:59:52 UTC
Our company has spent considerable time introducing single-sign on infrastructure to remove cases where our uses need to enter their password. Our users log onto their systems, both Windows and Linux, using smart cards. They are issued a Kerberos key in response to their usage of the smart card, and are able to access their desktop. From their, access to their home directories themselves are encrypted with those keys. The gnome keyring is incredibly useful. It allows the users to organize their credentials to other systems outside our own, web sites, IM, etc. However it has a big downside in our environment: You are forced to make a password for it! I would very much like to have a default gnome-keyring which doesn't require it's own password. It is assumed that access to the files that make up the keyring are already encrypted or secure. There is no reason to do it again. Additionally it bypasses our current desire to have users enter no passwords for internal systems.
I am in a similar position, where users who have passed our single sign-in process are being nagged for their gnome keyring master password in order to access wireless networks, email, etc. It's a good idea, but there needs to be a configurable password policy for master passwords (min length, with 0 a legal value, aging, etc.).
Gnome Keyring now uses PAM and ties into the user's login password. This will be included in the next release of gnome-keyring and Gnome. It seems this would solve the problem you're experiencing. It fits in very well with single sign on now. BTW, if either of you have time, I'd love to have your input and/or testing on the new PAM functionality from a corporate point of view. http://live.gnome.org/GnomeKeyring/Pam Do you think this'll solve your problem? If not please reopen this bug.
The pam solution doesn't work for people using gdm autologin (pam is not used there) nor mobile devices, reopening. Do you think it'll would be possible to allow to set an open mode when no authentification is required?
The PAM solution DOES NOT SOLVE MY ISSUE. The PAM solution relies on local machine operations being used to CHANGE the password. This is not reality. Users on our network can change their "network password" in a variety of ways: through web interfaces, Windows desktops, Linux desktops; HR can change it for a given user. A user's management can change their password. My boss can change my password. This all happens completely outside of the scope of PAM. Additionally for users which do not use passwords to authenticate, it fails completely. We have users who use smart cards. PAM will authenticate with this, but there is no plain text password by which to decrypt the keyring. So my existing bug request still stands. I need a way to hard code the Gnome keyring password to nothing and unlock it without prompting the user.
Yes, understood. Had folks responded earlier, we might have gotten such a change thought out and included in the 2.20 releases. But no matter, looks like a good idea for 2.22.
Sorry about that. As a naive user making a suggestion about implementation: I might accomplish this by introducing a single new gconf key for a hard coded password. If present this key would preseed the existing logic to create a new default keyring, as well as the logic to unlock the default keyring. Existing logic would remain the same. A simple up front check for the gconf key to avoid prompting would be the hardest part of the change. I might then integrate such an option into the UI for gnome-keyring... but then again I might not. Maybe it's completely site specific and something that should be configured by a non-desktop toolset. Sites would be able to use existing (or not existing) gconf mandatory settings frameworks to accomplish this goal.
Interesting. But gnome-keyring currently has no gconf dependency. A problem that has come up before. However it's not super easy to add a dependency either since for most users gnome-keyring starts way before any gconf daemon or other parts of the user session have come alive. How about this approach: Add a command line tool: gnome-keyring-tool. Among other things this tool would allow creation of keyring files. You could then roll out a keyring with a blank password to your new users. Perhaps, even populate that keyring with some contents relevant to your organization.
And a "blank password" would be tried before prompting the user for a password? This would be fine, but obviously non-ideal, as it requires a large deployment to step outside of a designed system for doing these things (gconf) and learn new tools and methods. In my case at least, the only thing I use to push settings is gconf. I'd now have to use something else, which is capable of copying files to user's home dirs. A system I do not currently have, and do not want to build unless required for a reasonable reason. This might be that reason. Still, gconf would be nice. gconf is started on demand, anyways... so actually I don't see why this would be a problem.
Yes it would be nice to use gconf. I'll look into it further. Before I work on this, I've been evaluating how other desktops handle this issue. KDE allows blank passwords. It seems MAC OS does not. Interesting that MAC OS X has the same problem with syncing the keychain password with network password changes: http://docs.info.apple.com/article.html?artnum=301364
Yeah, I do find it odd that Apple has not solved it. Windows XP solves it by storing the passwords in clear text in the user's registry fork and assuming that access to this data is governed by a secure policy. http://support.microsoft.com/kb/306992 Which seems reasonable to me. Once you've compromised the user's account, you can compromise the keyring daemon any number of ways: a) copy the keyring off of ~ to the network and brute force them elsewhere. b) pop up a dialog asking the user to enter his gnome-keyring password c) attach a debugger to gnome-keyring-daemon itself d) attach a debugger to any existing user process and just steal the information It's not really required to pretend that this information is secure from other processes running in the user's session. In this sense, I personally would like to use an empty password for the gnome-keyring on my local box. I'm annoyed by the prompts and don't really feel I get anything of value except storing all of my passwords in one spot where applications can access them.
One interesting thing of note: gnome-keyring supports encryption keys (ala X.509 or SSH etc...) When a user uses a blank password those encryption keys will be effectively unprotected.
Done and committed to SVN trunk. * Warns the user when they don't enter a password but allows them to continue. * New cleartext keyring format. Keyrings stored without a password this way will not open on previous versions of GNOME. * The daemon does not offer save passwords for keys or chain the passwords for other keyrings into a non-encrypted keyring. gconf policy is something that we need to looked into at a later date.
I want to say that I'm quite pleased with the solution as you described. It elegantly takes care of the issue. Saving passwords for other keyrings, such as x509/GPG, in this circumstance, does seem self defeating. If you didn't want a password for your x509/GPG keyring, then simply don't give it one and secure the files. This places the burden on the right system to protect it's own information. Thanks!