This isn't a security issue, and there is no good way to fix it.
There, I've said it. Now, here's some background:
Although people are talking about Seahorse, the actual application that manages passwords is called GNOME Keyring. GNOME Keyring is an application that manages a user's authentication information, such as user names and passwords. It stores the authentication information in one or more encrypted databases, called keyrings. A password, supplied by the user, is required to unlock a keyring, at which point all the information contained within is decrypted and is made available to applications via the libgnome-keyring library. It is similar to the Keychain in Mac OS X, and Protected Storage in Microsoft Windows.
Traditionally, a desktop application that needed to remember a user's password, such as an email or an instant messaging program, would store the password in a hidden config file in the user's home directory. Appropriate permissions would be set on the file to make sure other local users can't read it.
Sometimes, passwords stored in this manner would be obfuscated using a reversible scheme, as the password needs to be converted back to plain text in order to be used. This would provide a false sense of security. Users inspecting the file would think the passwords were encrypted, but a myriad of little recovery scripts and on-line converters were available to anyone who knows how to perform a Google search.
A password managing daemon, such as GNOME Keyring, increases the security of stored passwords for the following reasons:
- Passwords are stored in a database that uses real encryption, not just an obfuscation scheme
- A single code base needs to be audited to make sure no vulnerabilities exist in the encryption algorithms that are being used
- The database is protected by a password that is known only to the user who unlocks it
- Since the database is encrypted, no other user or bootable CD can recover the stored passwords if the unlock password is not known
So, if GNOME Keyring increases the security of user credentials, why can you see your passwords exposed in plain text when you open Seahorse? Because you've unlocked the keyring using your login password.
Although GNOME Keyring supports multiple keyrings, there is only one by default, called “login”. This keyring is automatically unlocked by a PAM module when logging into a GNOME desktop. When the desktop session is closed, the keyring is locked. When the keyring is in an “unlocked” state, the database files are decrypted using the decryption password and all the contents are in memory for gnome-keyring-daemon to access.
Now, the attack scenario that has been talked about this past week has been leaving your computer unattended, and an attacker using Seahorse to access your clear text passwords. This has been criticized as being a security issue, and a few “solutions” have been suggested to “fix” the issue. Here are some of the scenarios proposed:
Scenario 1: Ask for the user's password before displaying the clear text keyring contents.
This scenario doesn't work in practice. Once the keyring is unlocked, the contents are available under the user's security context. Since the GNOME Keyring daemon is under the user's security context, the intruder has every privilege necessary to simply bypass the authentication step and directly read the unencrypted keyring from memory. Even if Seahorse asked for a user password, nothing could prevent the intruder from simply downloading a “reveal passwords” application from the Internet or a USB key. There is no difference in time or skill required to open Seahorse and display passwords, or to type “gnome password revealer” in Google and execute the first application available for download. The GNOME Keyring project has a web page to explain this.
Even worse, the fact that a password would be required in Seahorse would make the user think that a password is required to see the clear text information. This would give the user a false sense of security. If Seahorse asks for a password, but a five line python script can bypass the password, bug reports would change from “Seahorse displays clear text passwords” to “Seahorse authentication can be easily bypassed”. This scenario doesn't solve the problem.
Scenario 2: Make keyring session expire automatically after a certain time.
If the keyring session expires automatically, such as every 15 minutes, it becomes useless. The purpose of the keyring is to store passwords that are needed by applications. With keyring session expiration, Evolution can't automatically check for new mail, Empathy can't auto-reconnect to instant messaging networks, the wireless connection can't re-authenticate to access points.
If you expire the keyring session every 15 minutes, you will probably need to type in your password every 15 minutes. Besides, if you leave your computer unattended, 15 minutes is long enough for an intruder to steal your passwords. This scenario doesn't solve the problem.
Scenario 3: Make the keyring daemon run as root or as a dedicated user.
The idea behind this is to have a central daemon that would authenticate users and applications before giving out passwords. Since the daemon doesn't run under the user's security context, no amount of hacking by an intruder in an unlocked desktop session would result in gaining access to the unlocked password database.
Although this scenario may seem appealing, it would probably be less secure than the current approach. If we have a central daemon that serves all users, a programming vulnerability could result in other users gaining access to your confidential information. Besides, if your desktop applications, under your security context, can gain access to the passwords they need, so can an intruder in your security context. The intruder's script can simply spoof the desktop applications themselves to get the passwords, or get them out of the application's memory. This scenario doesn't solve the problem.
Scenario 4: Stop using GNOME Keyring.
Well, GNOME Keyring was created to solve the problem of people writing down their passwords everywhere, including text files or their computer, and the problem of applications storing passwords in text files. Removing GNOME Keyring would decrease security to the state it was before. This scenario doesn't solve the problem.
Scenario 5: Locking the desktop session when stepping away from the keyboard.
Now we're getting somewhere!
Since the attack vector that's being discussed is an intruder gaining physical access to an unlocked desktop, the simplest way to prevent this from happening is to lock the desktop when you leave it unattended.
If someone gains access to your desktop, your passwords are not the only thing they can access. Who needs your email password, when they have access to your whole mail file?
Even if we assume GNOME Keyring could be made attacker proof, we would need to do the same for every desktop application. An intruder could, in a few seconds, install a Trojan horse downloaded off the Internet that runs in the background and emails him your passwords as soon as your desktop applications use them. The same application could intercept your sudo password, and become root to access the GNOME Keyring data. Absolutely no technical skill is required to do this.
Leaving your desktop unattended exposes all your confidential data to an attacker, not just your passwords.
Game Over.
Recommendations:
- Always lock your screen when you leave your computer unattended. This is akin to locking your front door when leaving the house. Hit Ctrl-Alt-L, select “Lock Screen” from the user switch applet, or put the “Lock Screen” applet somewhere in your panel for easy access.
- Set a low screen-saver idle timeout, for example, 5 minutes. If you forget to lock your session, it will do so automatically after a couple of minutes, reducing the time your confidential data is exposed.
And remember: This isn't a security issue, and there is no good way to fix it.
