Comment 6 for bug 881464

I have performed a shallow security audit of keystone. The code audit was not deep because "Keystone is very young and developing very fast." -- http://docs.openstack.org/trunk/openstack-identity/admin/content/what-is.html. With that said, here is my review:

Package review:
- Does not run as root
- Has test suite in the build
- Listens on all interfaces by default, on ports 5000/tcp and 35357/tcp (admin interface)
- Documentation on keystone is scant and there are no manpages for the binaries shipped in keystone
- no sudo fragments
- no DBus services
- no setuid/setgid binaries
- By default, does not use ssl. Since access to keystone is necessarily over the network and considering that Keystone/Nova/Glance/Quantum bits are likely on a trusted network (though they should use SSL as well), the most important bit seems to be the User to Keystone interaction, as that is where the password is passed and the token used by the other services is received. If the password or token is snooped then an attacker can do everything as that user.

Code review
- no privileged operations
- no processes spawned
- file handling seems sane
- keystone-control has, which shouldn't strictly be a problem because of Yama, but should be fixed regardless: os.environ['PYTHON_EGG_CACHE'] = '/tmp'
- correct example uses of ssl does not seem to be present. /etc/keystone/ssl.conf is shipped, but this is an example for tests and is confusing. /etc/keystone/keystone.conf has comments for how to use SSL, but only if using a local CA. It would be much better if it were commented to also include a section on using SSL with a proper CA from ca-certificates
- Doesn't seem to be any input validation on 'marker' in get_marker_limit_and_url() from keystone/controllers/__init__.py. It isn't clear at this time if this can be used for SQL injection, but 'marker' is passed unvalidated from get_marker_limit_and_url() all the way to session.query() (part of sqlalchemy) in endpoint_get_by_tenant_get_page() from endpoint_template.py.

Recommendations from security team for MIR approval:
- provide documentation for keystone, especially man pages
- provide documentation on how to correctly use SSL certificates, not just snakeoil or self-signed with your own CA (manpages and server documentation ideally)
- fix the /tmp file issue
- perform input validation an all variables returned in get_marker_limit_and_url() (keystone/controllers/__init__.py) or demonstrate where this is already being performed (and therefore why this is not needed)

Ideally, Ubuntu would also have tools or adjust packaging to properly configure keystone for SSL, with helpers for the various other openstack services utilizing keystone so all could also benefit. Since keystone is an identity service and a key component of openstack, it begs the question why it would be used without SSL at all. ssl-cert may be helpful here.