OpenStack Compute (Nova)

nova-compute should not address DB directly (a.k.a. root SQL password in conf)

Reported by Joe Gordon on 2011-08-08
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Wishlist
Unassigned

Bug Description

Although the nova.conf file's permissions are restricted to 640, giving every compute server the MySQL root password, as according to the cactus documentation, does not follow the principle of least privilege.

Documents that refer to root MySQL password on compute servers:
http://docs.openstack.org/cactus/openstack-compute/admin/content/configuring-multiple-compute-nodes.html
http://docs.openstack.org/cactus/openstack-compute/admin/content/setting-flags-in-nova-conf-file.html

If an attacker successfully exploits a flaw in the hypervisor (as have been found in KVM and XEN in the past), the attacker can easily tamper with the MySQL database, wreaking havoc on the OpenStack Cloud.

An attack on the hypervisor should be limited in scope to individual compute servers.

Brian Lamar (blamar) wrote :

I don't see how this is a bug, much less a security vulnerability. There is nothing that can/should be done in the code to prevent this so I'm guessing your beef is with the openstack-manuals project. Feel free to submit this bug report there?

Joe Gordon (jogo) on 2011-08-17
description: updated
description: updated
Thierry Carrez (ttx) wrote :

@Joe: how do you suggest we improve that ? get every database call through a queue and get the queries picked up by some database action listener ? Narrow down permissions so that the DB user used by nova-compute can't do as much damage ?

This is a pretty well-known situation, and not really a directly-exploitable vulnerability (but rather something that can be improved in the architecture for more resilience). Do you agree to open this bug publicly ?

Joe Gordon (jogo) wrote :

@Thierry: I think both are good options, perhaps moving the DB call to work through a queue can allow for other services to subscribe to specific DB updates? While it looks like the easier option is to narrow the nova-compute DB user's permission the question is what is the better solution in the long term?

Yes, I do agree this should be bug should be made public.

Joe Gordon (jogo) on 2011-11-28
security vulnerability: yes → no
visibility: private → public
Thierry Carrez (ttx) on 2011-12-01
Changed in nova:
importance: Undecided → Wishlist
status: New → Confirmed
summary: - nova-compute doesn't follow principle of least privilege; root SQL
- password in nova.conf
+ nova-compute should not address DB directly (a.k.a. root SQL password in
+ conf)
Russell Bryant (russellb) wrote :

Since we've got this covered by a blueprint that is well underway and scheduled to be done in Grizzly, I think we can just close this bug out.

Changed in nova:
status: Confirmed → Opinion
Russell Bryant (russellb) wrote :

This blueprint has been implemented

Changed in nova:
status: Opinion → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers