6 July 2018, in openstack, devstuff, tripleo
Security is an important thing. Especially nowadays, when you can read, hear tons of companies and entities getting hacked in funny ways.
Currently, the TripleO project has some issues with too widely opened sudo rules. They allow standard users to basically own the whole node without any password.
Of course, you’ll still need an access (remote or local) to the node in order to profit from the sudo. But it might be triggered without a shell, if some service using one of those power users have a flaw.
This can’t stay as is, and should be corrected, of course. Security is also important in Open Source projects, especially an attack surface as big as OpenStack.
In order to correct that bad situation, two specifications are currently under review, and are to be implemented in Stein release (due for next year).
This kind of calls also creates some issue with the rights of generated files, and leads to other sudo calls we don’t want to see.
The solution isn’t easy though. In order to prevent any
the sudoers, we’ll need to refactor the code, and introduce
oslo.privsep, a python library
aiming a secure and clear privilege escalation, with proper filters and the
Basically, in the tripleoclient case, we will need to replace all the
os.chown calls by plain
rootwrap subprocess calls. The
os.chown isn’t the only one, there are most probably other things that
will need to be corrected and correctly isolated. And as
some services are launched as another user
during the deploy process, we will also need to take those kind of calls out,
and push them in a separated script, called with the
The advantages of using
oslo.privsep are multiple:
The second proposal aims plain
calls from shell script and ansible. It will not require any code refactoring,
but more a log review in order to catch all the reall sudo needs, and list them
There again, the goal is to prevent any unwanted privilege escalation via
In the end, when both those proposals are accepted and implemented, we will end up with a more secure TripleO deployment, more secure nodes, and less issues with people refusing to deploy OpenStack due to those bad sudo practices.
So, if you’re interested in Security and OpenStack, you definitively will review those two proposals and take part in this revolution.