New spec for TripleO: integrate oslo.privsep in tripleoclient

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).

The first one aims python scripts. Currently, at least in python-tripleoclient, there are wild calls to sudo in order to call itself. This is one example among others, and it’s pretty ugly.

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 NOPASSWD:ALL in 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 like.

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 rootwrap instead.

The advantages of using oslo.privsep are multiple:

The second proposal aims plain sudo 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 in the sudoers.d/user file.

There again, the goal is to prevent any unwanted privilege escalation via passwordless sudo calls.

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.