Keeping the last subject, today I’ll write a little about the Gnome Keyring security. As presented in the last post, the Gnome Keyring is responsible for storing users sensitive information in encrypted databases called keyrings. I’ve shown how to create an Keyring and store some secrets. But now I ask, are those information secure? They may be or not, it’s up to you.

There is a recurrent discussion about the Gnome Keyring behavior. When we log on, the Session Manager unlock the default keyring with your logon password to prevent many popups asking the user if they wan’t to grant access to a certain application. Many people may say this is a security flaw, I don’t totally agree. Gnome Keyring also uses the application name to ensure the permission. Let’s see an example. I’ll suppose we’re developing an certain application called  ‘MyApp’ and it will create a simple keyring. The following snippet would do the trick:

import gnomekeyring as gk
import glib

APP_NAME = 'MyApp'
KEYRING_NAME = 'MyKeyring'

glib.set_application_name(APP_NAME)

keyrings = gk.list_keyring_names_sync()

# If this keyring already exist, let's remove it
if KEYRING_NAME in keyrings:
    # Gnome Keyring Daemon may ask for a password here
    gk.delete_sync(KEYRING_NAME)

# If anyone asks, the password is 'mypasswd'
gk.create_sync(KEYRING_NAME, 'mypasswd')

id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'magnun@Neptune:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (key=%i)'%(key)

id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'guest@Neptune:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (key=%i)'%(key)

id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, 'magnun@Jupiter:22', {'application':APP_NAME}, 'passwd', True)
print 'New host added (id=%i)'%(id)

A part of this application may request access to the stored secrets, let’s say that it’s made by this inspector:

#!/usr/bin/env python

import gnomekeyring as gk
import glib

APP_NAME = 'MyApp'
KEYRING_NAME = 'MyKeyring'

glib.set_application_name(APP_NAME)

keyrings = gk.list_keyring_names_sync()

# If this keyring already exist, let's remove it
if KEYRING_NAME in keyrings:
    # Gnome Keyring Daemon may ask for a password here
    gk.delete_sync(KEYRING_NAME)

# If anyone asks, the password is 'mypasswd'
gk.create_sync(KEYRING_NAME, 'mypasswd')

def add_item(username, password, server, protocol, port):
    atts = {
            'application': APP_NAME,
            'username' : username,
            'server' : server,
            'protocol' : protocol,
            'port' : str(port),
           }
    name = username+'@'+server+':'+port
    id = gk.item_create_sync(KEYRING_NAME, gk.ITEM_GENERIC_SECRET, name, atts, password, True)
    return id

id = add_item('magnun', 'mypasswd', 'Neptune', 'ssh', '22')
print 'New host added (id=%i)'%(id)
id = add_item('guest', 'mypasswd', 'Neptune', 'ssh', '22')
print 'New host added (id=%i)'%(id)
id = add_item('magnun', 'mypasswd', 'Jupiter', 'ssh','22')
print 'New host added (id=%i)'%(id)

All the passwords will be printed. Let’s pretend that you’re writing another application ‘MyApp2’ and it will try to access the passwords stored by ‘MyApp’. Obviously, Gnome Keyring will will display a dialog asking if we want to grant MyApp2 access to that Keyring:

Gnome Keyring Access Dialog - Does MyApp2 should access this keyring item?

This happens because Gnome Keyring uses the application name and path to make decisions, as an example I’ve tried to access the ‘MyKeyring’ keyring using Seahorse and received this dialog:

Seahorse

Attention to the path /user/bin/seahorse

But if we change the application name for ‘MyApp’ the untrusted application will freely access the stored secrets. Why it happens if they’re different applications? As I said, Gnome Keyring uses the application path to make decisions but since all Python applications use the path /usr/bin/python2.6 (in this case) this "protection" become inexistent. Now that’s a flaw! You can make any untrusted python application become trustful just by changing it’s application name. A bug report was filled but the solution still pending. To avoid this we can use the lock feature which will be presented in the next post!