Proposal for inclusion in desktop: gnome-keyring

[Alexander Larsson <alexl redhat com>]

Over the last two weeks I've been writing a gnome keyring manager,
called gnome-keyring, that I'd like to propose for inclusion in the
Gnome 2.6 desktop. I also hope that the API shows itself stable and
capable so that we can make it a platform API in 2.8. 

The main reason I wrote this code, and why I'm proposing it for 2.6 is
that I need it in order to make the authentication mechanism and
process authentication sharing in gnome-vfs work in a sane way.

Thus, the plan is to extend the authentication mechanism in gnome-vfs
to be more comprehensive (much needed), and make the default
authentication dialogs in libgnomeui use gnome-keyring to implement
password storage. These changes are mostly desktop internal and won't
really affect the public API much.

The current code is available in the gnome-keyring module in cvs. Most
of the important functionality is implemented, although the UI and
some other parts clearly need more polishing and testing. Its also
currently lacking a gui to manage the keyrings. API-wise I think the
public library is mostly done. There is some additional helper
functions I want to add that aren't yet in there, but I'll add those
this week. There might also be some changes needed as I start using the
API for gnome-vfs, but I don't expect much changes, and I hope to 
get that done before the API freeze.

Let me describe what gnome-keyring does:

Conceptually, the keyring manager manages a set of keyrings. Each
keyring contains a set of keyring items, where each item stores a
secret, typically a password.  To identify the items, it has a
set of named attributes, with values that are utf8 strings or
integers. Each item also has additional data such as: mtime, ctime,
display name and item type. Keyrings are normally locked, meaning that 
their content is encrypted, and not available for apps to use without
the keyring password.

Apps would use this by issuing a search for a password with the known
information. Say you want to log in to "smb://someserver/someshare",
you'd then query for an item of type network password with attribute
server="someserver", path="someshare", protocol="smb" and you'd get
back a list of items that matches this, where you can read the secret,
and also the full attribute list containing username, nt domain etc.

If a search or any other operation needs access to an item on a
locked keyring then the user will get a dialog asking for the master
password of the keyring to unlock it. Each item also has an access
control list, which controls what apps are allowed access to the
item, so that when an app tries to access an item it isn't allowed to
access the user will get a dialog where he can allow or deny the
access. 

There is also a keyring named "session", which isn't backed by a
file. This can be used to store passwords for the current session
only.

Implementation-wise gnome-keyring is very similar to ssh-agent. You're
supposed to launch the daemon early in your session and it'll output an
variable that you set in your environment. This will let applications
find the unix domain socket to communicate with the daemon, and will
make the daemon connect to the right session and the right X display.

The daemon itself is a very small, glib-only application that uses a
custom protocol over unix sockets (can't use Corba because we need
some special features like SO_PEERCRED, and I want the daemon to be
minimal for security reasons). All user interaction is done by a
separate program (gnome-keyring-ask) that the daemon spawns when
needed (if it notices that DISPLAY is set).

The keyring files are stored in ~/.gnome2/keyrings, and are encrypted
with the AES block cipher and SHA1 is used for hashes. All data about
the items is encrypted, except item type and a hashed version of the
attributes. The hashed attributes allows us to match on items even
when the keyring is locked, so that you'll only be prompted for the
keyring password if a search really matches an item in a locked keyring.

The keyring daemon itself is GPL, and there is a small LGPL library
(libgnome-keyring) that implements the public API for talking to the
daemon.

There are certain security aspects in the storage of passwords like
this. If the user choses a good password, the passwords are safely
stored in encrypted files when the user is not logged in, but when the
user is logged in and a keyring is unlocked, both the keyring
password and all the secrets stored in the keyring are stored in the
memory of the keyring daemon. So, if someone has root on the machine,
he'll be able to read the memory of the daemon and steal your
passwords (i.e. only use this on machines you trust). Other users on the
machine will not be able to do this, because only processes with the uid
of the daemon will be allowed access.

There is even some protection against user of your own uid,
ptrace and process memory access can be disabled by making the binary
chmod u-r (on Linux), and the ACLs allow some form of protection
against buggy applications, but not perfect protection against malicious
code. To get the ACLs safe against malicious code (viruses, trojans,
etc) we would need to extend gnome-keyring with some selinux features.
This could be done in the future without changing the APIs.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a war-weary small-town paranormal investigator with no name. She's a 
bloodthirsty blonde traffic cop living homeless in New York's sewers. They 
fight crime!