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.
** Changed in: keystone (Ubuntu)
Status: New => Incomplete
** Changed in: keystone (Ubuntu)
Assignee: Jamie Strandboge (jdstrand) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/881464
Title:
[MIR] keystone
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/881464/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
