Insecure rootwrap usage

[Tristan Cacqueray]

Reported by Benjamin Deuter of SUSE:

Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here:

https://security.openstack.org/guidelines/dg_use-oslo-rootwrap-securely.html#incorrect

For example this shouldn't be authorized:

sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow

[Tristan Cacqueray (tristan-cacqueray)]

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.

[Tristan Cacqueray (tristan-cacqueray)]

Assuming this only affect localhost user and that rootwrap argument can not be set arbitrarily by remote user, I guess this is at best a class B2 or perhaps C1 according to VMT's taxonomy: https://security.openstack.org/vmt-process.html#incident-report-taxonomy

This also affects quite a few filters, e.g.: mount, tee, chown, dd, cp, chgrp, cat

[Jeremy Stanley (fungi)]

At a minimum, I think we can continue this in public because it's a known issue. The rootwrap base implementation was an okay idea in theory, but in practice many projects shipped terrible default configurations which bypassed any actual security afforded by the framework. As a result, rootwrap is itself on the path to deprecation with https://docs.openstack.org/developer/oslo.privsep/ as its eventual successor.

I agree this is probably a B2 class report (or maybe B1 if rootwrap replacement with oslo.privsep happens quickly).

[Jeremy Stanley (fungi)]

In a private E-mail reply, Benjamin agreed with the suggestion to proceed with this report in public for now. As such, I'm triaging it as class B2 ("a vulnerability without a complete fix yet, security note for all versions, e.g., poor architecture / design"). The security note normally suggested by B2 is probably not warranted either given the existing treatment in the security guide, linked from the initial report.

[Sean Dague (sdague)]

This is too vague to be actionable. There is one example, and it's not clear where in the system the concern is. And the kinds of changes to make this be as restricted as one would like really don't lead well to a bug, but would require a more systematic push to really embrace something like privsep.

In general, the use of root wrap on nova-compute is honestly pointless in my pov. Besides chmod, cat, dd and a few others are running more or less unrestricted. It just doesn't make for a useful security model.

[Michael Still (mikal)]

Well, there is proposed code is up to start moving to privsep, but it's not
a priority right now...

Michael

On 28 Jun. 2017 8:41 pm, "Sean Dague" <email address hidden> wrote:

> This is too vague to be actionable. There is one example, and it's not
> clear where in the system the concern is. And the kinds of changes to
> make this be as restricted as one would like really don't lead well to a
> bug, but would require a more systematic push to really embrace
> something like privsep.
>
> In general, the use of root wrap on nova-compute is honestly pointless
> in my pov. Besides chmod, cat, dd and a few others are running more or
> less unrestricted. It just doesn't make for a useful security model.
>
> ** Changed in: nova
> Status: New => Incomplete
>
> --
> You received this bug notification because you are a member of Nova Core
> security contacts, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1700501
>
> Title:
> Insecure rootwrap usage
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions
>

[Goutham Pacha Ravi (gouthamr)]

In Manila, we've discussed migrating off of rootwrap, to privsep - and are yet to find an owner to complete that work. We'll hopefully do that soon. However, I agree this bug is wide open. We'll use a different tracker to call out the tasks to deprecate the usage of rootwrap.