nova-rootwrap does a poor job of validating parameters

Bug #948520 reported by Joe Gordon
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Cinder
Won't Fix
Wishlist
Unassigned
OpenStack Compute (nova)
Invalid
Wishlist
Unassigned
oslo-incubator
Invalid
Medium
Unassigned

Bug Description

Although nova-rootwrap does limit which commands can be run as root, it doesn't validate the parameters passed through.

For example, '/bin/dd' is allowed by by 'nova/rootwrap/compute.py' which can be exploited in the following fashion:

'sudo nova-rootwrap dd if=/tmp/mypw of=/etc/passwd'

This means that if someone can get nova user access they can gain root access.

Tags: rootwrap
Revision history for this message
Thierry Carrez (ttx) wrote :

Completely agree. We still need to add custom CommandFilters for a lot of commands, in particular those chown/chmod/dd running on compute/network nodes, if we want to efficiently prevent nova->root privilege escalation.

nova-rootwrap just provides the framework allowing to do that (previously we used plain "sudo" which didn't allow any filtering at all), and provides node separation (so the user-facing nova-api can't run any command as root at all). So it's an incremental improvement compared to previous versions, but it's not perfect yet.

That was on my TODO for essex by I just didn't get to it. Will do in Folsom though, if nobody beats me to it.

Changed in nova:
importance: Undecided → Wishlist
status: New → Triaged
tags: added: rootwrap
Revision history for this message
Joe Gordon (jogo) wrote :

Thierry,

This is still present in Folsom:

ubuntu@ip-10-202-101-252:~$ sudo /usr/local/bin/cinder-rootwrap /etc/cinder/rootwrap.conf dd if=/etc/shadow
root:!*:15507:0:99999:7:::
daemon:*:15507:0:99999:7:::
bin:*:15507:0:99999:7:::
sys:*:15507:0:99999:7:::
sync:*:15507:0:99999:7:::
games:*:15507:0:99999:7:::
man:*:15507:0:99999:7:::
lp:*:15507:0:99999:7:::
mail:*:15507:0:99999:7:::
news:*:15507:0:99999:7:::
uucp:*:15507:0:99999:7:::
proxy:*:15507:0:99999:7:::
www-data:*:15507:0:99999:7:::
backup:*:15507:0:99999:7:::
list:*:15507:0:99999:7:::
irc:*:15507:0:99999:7:::
gnats:*:15507:0:99999:7:::
nobody:*:15507:0:99999:7:::
libuuid:!:15507:0:99999:7:::
syslog:*:15507:0:99999:7:::
messagebus:*:15507:0:99999:7:::
whoopsie:*:15507:0:99999:7:::
landscape:*:15507:0:99999:7:::
sshd:*:15507:0:99999:7:::
ubuntu:$6$vF9ctnGz$Z5oxwo9yRyHqwNMId9ptusHmYAB1f7KZLQqX5.NFpMRVvYOBiTYgL8ti0xNlS1rCQqUGl9UWap2qI9o3EFfSI1:15573:0:99999:7:::
libvirt-qemu:!:15573:0:99999:7:::
libvirt-dnsmasq:!:15573:0:99999:7:::
rabbitmq:!:15573:0:99999:7:::
mysql:!:15573:0:99999:7:::
1+1 records in
1+1 records out
905 bytes (905 B) copied, 0.000288851 s, 3.1 MB/s

Changed in cinder:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
James King (jking-6) wrote :

Thierry;

Did you have a specific plan of attack for this bug?

I'm getting ramped on Cinder and am looking for some low-hanging fruit to get my feet wet.

Revision history for this message
Thierry Carrez (ttx) wrote :

The CommandFilter for dd could be replaced by a RegExpFilter to better control the allowed arguments.

Revision history for this message
James King (jking-6) wrote :

Couldn't the RegExpFilter be fooled by simlinks?

Revision history for this message
Thierry Carrez (ttx) wrote :

If the regexp anchors to a root-owned directory (in which Nova can't create symlinks) and checks you don't do path traversal, it should be alright...

Alternatively we could add a more complex filter that checks that the file affected actually lives in a given directory. Something like "RealFileFilter, chown, root, /var/lib/nova/" that would check that would check that whatever is passed to chown actually lives in /var/lib/nova/ (would resolve symlinks and path traversal before allowing the command).

Changed in oslo:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Thierry Carrez (ttx) wrote :

This needs to be fixed in filter definitions for each project, not in the lib itself.

Changed in oslo:
status: Triaged → Invalid
Revision history for this message
Sean Dague (sdague) wrote :

Honestly rootwrap is unfixable in the nova compute case because there is too big a surface it needs to run as root. I think realistically we should just dump rootwrap for n-cpu entirely.

Marking as won't fix for that reason.

Sean Dague (sdague)
Changed in nova:
status: Triaged → Confirmed
Changed in nova:
status: Confirmed → Invalid
Changed in cinder:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.