the login password is stored in the user's keyring

It would appear this is being created by gnome-keyring itself if you login and don't have a login keyring.

@marc, negative. i have a separate /home partition on lvm, yet this key had been present in my key ring before i got freaked out by a minimal reproducible test case.

BTW, will a security bulletin be issued advising beta testers to remove this key from their key rings? Or better, will a cleaner-like application be released?

I should have filed this bug way earlier but was too busy with other deadlines, my bad.
You guys ok with this being public, just to be sure?

@Jesse: yes, gnome-keyring will add it to an existing login keyring also.

Once we fix the issue, we'll get the updated package to automatically fix existing keyrings. If this gets fixed after release, we'll issue an advisory for it.

I've marked the bug public as this is highly discoverable anyway, and leaving it private will just create a bunch of duplicate bugs being reported.

I am not absolutely sure the problem is in gnome-keyring, it could be the installer. I chose gnome keyring because a bug has to be filed against one package ... So is it still a good idea to tell upstream now there's a problem with Gnome Keyring?

the issue is not an installer one, it happens on upgraded systems too

I had the entry in my keyring on an upgraded system as well, so I can confirm it isn't an installer issue.

I removed the item via Applications/Accessories/Passwords and Encryption Keys, then restarted my session and things still seem to be working fine (evolution, ssh), though I don't know why it was added in the first place, so I can't say doing the same wouldn't affect others.

Notes:

 * Create a new user, log in the first time (no autologin) -> creates "login" keyring and "User Keys" password entry

After every action below, log out and back into GNOME:

 * Remove "User Keys" password entry -> no change, "User Keys" is not regenerated
 * Remove entire "Passwords: login" keyring -> "Passwords: login" keyring is recreated, but not "User Keys"
 * rm .gnome2/keyrings/login.keyring -> "Passwords: login" keyring is recreated (and login.keyring file), but not "User Keys"
 * rm .gnome2/keyrings/{login.keyring,user.keystore} ->"Passwords: login" keyring is recreated with "User Keys"
 * Remove "User Keys" password entry and rm .gnome2/keyrings/user.keystore -> "User Keys" password is recreated

Logging into a VT and starting gnome-keyring-daemon by hand does not recreate user.keystore, so it really seems to be pam_gnome_keyring.so.

This is an easier reproducer for developers, which mimics what the PAM module and autostart .desktop files do, but without the requirement to log out/in:

killall gnome-keyring-daemon
rm -v .gnome2/keyrings/*
export `echo s3kr1t | gnome-keyring-daemon --daemonize --login`
export `gnome-keyring-daemon --start --components=secrets`

This will put "s3kr1t" into the "User Keys" password in login.keyring. Running "seahorse" will show that. (Unfortunately there does not seem to be a CLI tool to dump a keyring).

I have a patch to stop the password from being added to the keyring, and also to remove it on upgrades. I sent it to upstream, but it's probably not an approach which upstream likes. Also, this most probably breaks this ominous user.keystore. I don't see how to use it in the first place, I contacted upstream (Stef) by email to clear this.

@security team: This is not _such_ a big deal IMHO, since the password is encrypted on disk, and can only be retrieved if the user is already logged in (at which point all the wifi passphrases, empathy accounts, and everything else stored in the keyring is also accessible). Thus it seems prudent to leave this to an SRU, until it's fully cleared with upstream. What's your feeling about this?

Thanks!

Package uploaded to ppa:ubuntu-desktop/ppa for testing.

@pitti: I think you can get info here on how to store things in the pkcs11 keyring: http://live.gnome.org/GnomeKeyring/ApplicationSetup.

Instead of using the users password to encrypt the user.keystore file, it would probably be more appropriate to generate a random password and use it, unless I'm missing an obvious use case where the actual user password is required.

I agree it's not a big deal in the case of trying to recover a user password from a user who isn't logged in. Malware, on the other hand could retrieve the current user's password from the keyring and use it to become root with sudo. I don't have a problem with issuing an SRU after the fact, as long as we write a tool/script to automatically remove the user's password upon upgrade. I also hope this doesn't escalate into a media frenzy if people start noticing their password is in there.

Obviously we can do an SRU/security update after the fact, but this does, as Marc pointed out, leave a root escalation path for malware or applications with a security hole. Perhaps worse is that it allows the malware call home with the password so that it can be used later to potentially login to the machine remotely, and then have full shell (and root if admin) without having to go through all the hoops of doing it within the malware itself.

Since this feature is not widely used, new in Lucid and seemingly not well documented in Ubuntu, wouldn't it be better to disable the feature (ie, use Martin's patch) and then restore the functionality using the upstream patch in an SRU later? This would plug the escalation issue as well as avoid a publicly announced USN.

Marc Deslauriers [2010-04-21 12:07 -0000]:
> as long as we write a tool/script to automatically remove the user's
> password upon upgrade

That's already contained in the patch, BTW. g-keyring-daemon removes
it on startup.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Just to keep you up to date, I got a reply from upstream, and it seems the patch goes into the right direction. He committed a patch upstream now, but apparently forgot to push. I contacted him again.

Jamie Strandboge [2010-04-21 12:38 -0000]:
> Obviously we can do an SRU/security update after the fact, but this
> does, as Marc pointed out, leave a root escalation path for malware or
> applications with a security hole.

That's a good point. Now that upstream has replied and confirmed that
having the password in the keyring was an accident instead of a design
decision to make other keyrings work, I have a much better feeling
about this, so I'll do an upload to lucid and try to push it right
after RC.

Upstream ack'ed the patch and committed it with a slight refinement, confirmed that the password shouldnt' be there at all (it's not a (bad) design choice to make those extra keyrings work), and I tested the hell out of it now.

Discussed with Steve and we agreed to push this into final, I uploaded it to unapproved now.

This bug was fixed in the package gnome-keyring - 2.92.92.is.2.30.0-0ubuntu3

---------------
gnome-keyring (2.92.92.is.2.30.0-0ubuntu3) lucid; urgency=low

  * Drop 04_clean_session_keyring.patch: This was a cleanup for users who
    installed Lucid Alpha versions and persisted until after Beta-2 and RC. No
    need to keep this extra code for the final release.
  * Add 04_dont_save_login_password.patch: Disable writing the login password
    into the "login" keyring as "Unlock password for: User Keys". It was never
    meant to be there in the first place (it just was an inadvertent side
    effect of the code reorganization in 2.29), and a freely accessible
    cleartext password for each application once the keyring is unlocked
    creates a root escalation path through sudo. Also, remove that particular
    key entry on upgrades. (LP: #566046)
 -- Martin Pitt <email address hidden> Thu, 22 Apr 2010 09:15:53 +0200